Internet Draft November, 2001 Document: draft-cai-ppvpn-vc-rsvp-te-00.txt Expires May, 2002 Martin Machacek Lior Shabtay Ting Cai Marty Borden Pascal Menezes Atrica, Inc. Terabeam Networks, Inc. Signaling Virtual Circuit Label Using RSVP-TE Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The virtual circuits for a provider provisioned virtual private network (PPVPN) using MPLS may be set up in a number of ways. This draft discusses the use of RSVP-TE as a VC setup mechanism. Cai, et. al. Page 1 Internet Draft VC-RSVP-TE Nov., 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1.Introduction.....................................................3 2.Conventions used in this document................................3 3.VC Models........................................................4 4.Motivation.......................................................5 5.Extensions to RSVP-TE............................................6 VC LABEL Object................................................6 VC LABEL REQUEST Object........................................8 Processing Rules..............................................10 6.Scalability.....................................................12 7.Refresh-Reduction Considerations................................13 8.Membership discovery............................................14 9.Security Considerations.........................................14 10. IANA Considerations...........................................14 11. Authors' Addresses............................................14 Acknowledgments...................................................15 References........................................................15 Cai, et. al. Expires April, 2002 Page 2 Internet Draft VC-RSVP-TE Nov., 2001 1. Introduction A provider-provisioned virtual private network (PPVPN) consists of a network with virtual circuits managed by the provider for the benefit of customers. This document describes methods applicable to PPVPNs that use MPLS as the virtual circuit (VC) mechanism. In a relatively small or isolated network, the provider may choose to set up VCs directly on the behalf of the customer. These MPLS VCs will likely have characteristics such as QoS that are determined by a SLS (Service Level Specification). We call this the direct-VC method, since the VCs are directly managed and not part of a more elaborate tunneling scheme (as below). For direct-VC MPLS PPVPNs, it is naturally of importance for the VC management to be sensitive to QoS needs. A second approach that is generally applicable is the tunneled-VC method. This approach has received attention in a number of drafts; notably, Martini et. al. proposed in [5] a method of encapsulating L2 PDUs in MPLS packets. The method uses a stack of two labels: one specifying the LSP tunnel across the MPLS network and the other identifying the virtual circuit (VC) to which the L2 PDUs belong. In [5], the tunneled-VC method distributes VC labels using LDP in downstream-unsolicited mode[2]. For both the direct-VC approach and the tunneled-VC approach we see advantages to allowing the use RSVP-TE [3] to distribute the VC labels. This draft proposes a simple extension to RSVP-TE to signal VC labels using RSVP-TE. The extension includes two new RSVP object classes, VC LABEL and VC LABEL REQUEST. The data formats, including their interpretations, are taken from [2] with only minor modifications required to the RSVP object format. This approach can help simplify implementations by supporting only one protocol, RSVP-TE, for virtual circuits and labeled paths. We will future discuss the motivation for this work below. We then discuss the data objects and the processing rules. Our discussion concludes with issues of scalability. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Cai, et. al. Expires April, 2002 Page 3 Internet Draft VC-RSVP-TE Nov., 2001 3. VC Models In the following text, the objects introduced and operations with them can be described mostly independent of the location of the endpoints used for virtual circuits. However, for clarity, it is much easier to refer to some typical examples when describing the usage than it is to deal with this abstractly. The first mode of using VCs we call the direct-VC approach. In this case the virtual circuit is from end to end, as in the following picture. Direct-Mode +------+ +------+ +------+ +------+ | LERa |---| LSR1 |---| LSR2 |---| LERb | +------+ +------+ +------+ +------+ <---------- VC LSP ----------> In the tunnel-mode, the virtual circuit is established within an existing LSP that was likely established for traffic engineering purposes. In this example, there are 2 stacked labels, a label for the forwarding adjacency of the TE tunnel and an inner label for the VC. Tunnel-Mode +------+ +------+ +------+ +------+ | LERa |---| LSR1 |---| LSR2 |---| LERb | +------+ +------+ +------+ +------+ <---------- Tunnel LSP ------> <---------- VC LSP ----------> A third mode is a hybrid of the two above. Here, a tunnel is established between LSRs, say for traffic engineering purposes. This tunnel appears to the LSRs as a direct VC, used for a forwarding adjacency. The VC tunnel is established end-to-end between LERs; the first LSR in the path must know to put this VC LSP within a particular tunnel LSP. From the LER's point of view, the VC tunnel appears as a direct-mode VC. At the LSR, the VC tunnel appears as a tunnel-mode VC that originated outside of the LSR. Cai, et. al. Expires April, 2002 Page 4 Internet Draft VC-RSVP-TE Nov., 2001 Hybrid-Mode +------+ +------+ +------+ +------+ | LERa |---| LSR1 |---| LSR2 |---| LERb | +------+ +------+ +------+ +------+ <- Tunnel LSP -> <---------- VC LSP ----------> 4. Motivation The main motivation for this draft is to give operators of networks using exclusively RSVP-TE based signaling the option to use the same protocol also for signaling of Virtual-Circuits. This can help to simplify and improve the manageability and maintainability of the network. For example, the operators of the network do not need to learn an additional protocol, can use similar management tools, and do not need to understand the interaction between the two different signaling protocols running on the same network. Additional benefits to the operator are possible reduced cost and increased reliability, as devices in the network need to execute fewer protocols, which means less resource consumption and fewer potential bugs in each device. Using two different signaling protocols concurrently may cause side effects and interference. For example, consider the case of using LDP for signaling VCs that are aggregated through an LSP, as in the hybrid-mode. Here, the VC signaling between the LERs (which may not be directly connected) may follow a path that is different than the path of the tunnel LSP. This is due to the fact that the LDP signaling is performed using TCP, which is usually forwarded in native IP. Native IP does not necessarily forward the packets in the path of the tunnel LSP that carries the signaled VCs. This situation could lead to an inconsistent failure decision, such as when the tunnel LSP fails but the LDP-session still works or when the LDP-session fails while the tunnel LSP is operational. It is desirable to consider a solution that avoids problems of mixed signaling methods. In addition to overall manageability considerations, there is the potential for increased functionality in RSVP-TE signaling of the VCs. RSVP-TE allows association of QoS parameters with specific VCs. This allows for fine-grained traffic engineering when needed. In some devices and network designs this can be an advantage. We give an example of this QoS capability, nicely illustrated by a hybrid-VC approach. Suppose that the PE devices are low-bandwidth Cai, et. al. Expires April, 2002 Page 5 Internet Draft VC-RSVP-TE Nov., 2001 devices that serve a small number of VCs. In this case it makes more sense to perform the aggregation on a larger-bandwidth intermediate LSR. A possible design is to let each VC be mapped to its own LSP going from the PE device to the other side through a number of intermediate LSRs, and have the first intermediate LSR aggregate a number of VCs through a tunnel ending at the last intermediate LSR. The VCs aggregated in one tunnel can be originating in different PE-devices attached to that LSR, as long as they are going in the same direction. This requires signaling the VCs using RSVP-TE, so that the intermediate LSRs performing the aggregation would be able to get the QoS and bandwidth-reservation parameters of the different VCs, as signaled by the PE devices. An additional advantage provided by RSVP-TE is easier support of fault tolerance. (See, e.g., [9], [10], [11] for background.) With fault- tolerance support, LSPs and VCs can survive resets, recovery after hardware failures, etc. This means fast recovery of service without needing to signal all LSPs and VCs after the failure. In RSVP-TE the support for fault tolerance mainly requires the device to maintain the LSPs and VCs information after the failure. LDP assumes a reliable transport, and uses TCP for this purpose, which makes it harder to support fault-tolerance. We believe that selection of signaling protocol for VCs should be conscious decision of every network architect based on analysis of network topology, services offered and other aspects of network design and should not be limited by lack of available standard solutions. 5. Extensions to RSVP-TE VC LABEL Object The VC LABEL object MAY be used in RSVP RESV messages when replying to RSVP PATH messages with VC LABEL REQUEST object. The VC LABEL object SHOULD only be interpreted by the originator of the VC LABEL REQUEST object at the ingress of the tunnel. Multiple VC LABEL objects MAY be present in one RESV message. If multiple VC LABEL objects with identical VC ID are present, the first object MUST be used while others MUST be ignored and notification to management SHOULD be generated. The VC LABEL Class number is 208 (see sect. 9) and currently only C-Type 1 is defined. The VC LABEL class is optional from RSVP point of view. Based on rules in Section 3.10 of [4] all label switch routers (LSR) that do not support this class MUST ignore the object and pass it unchanged. LSRs supporting the VC Label Request class MUST also support VC Label class. The VC LABEL object has the following format: Cai, et. al. Expires April, 2002 Page 6 Internet Draft VC-RSVP-TE Nov., 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |C| VC Type |VC info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC LABEL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Field MUST be set to zero on transmission and ignored on receipt. VC TYPE A 15-bit quantity containing a value that represents the type of VC. Assigned values are: VC Type Description 0x0001 Frame Relay DLCI 0x0002 ATM AAL5 VCC transport 0x0003 ATM transparent cell transport 0x0004 Ethernet VLAN 0x0005 Ethernet 0x0006 HDLC ( Cisco ) 0x0007 PPP 0x8008 CEM [8] 0x0009 ATM VCC cell transport 0x000A ATM VPC cell transport 0x000B MPLS Control word bit (C) The C bit is used to signal whether control word (as defined in [5]) will be used for the VC. C bit = 1 control word present on this VC. C bit = 0 no control word present on this VC. VC information length Length of the VC ID field and the interface parameters field in octets. If this value is 0, then it references all VCs using the specified group Cai, et. al. Expires April, 2002 Page 7 Internet Draft VC-RSVP-TE Nov., 2001 ID and there is no VC ID present, nor any interface parameters. The length must be multiple of 4. Group ID An arbitrary 32 bit value which represents a group of VCs that is used to augment the VC space. This value MUST be user configurable. The group ID is intended to be used as a port index, or a virtual tunnel index. To simplify configuration a particular VC ID at ingress could be part of the virtual tunnel for transport to the egress router. The Group ID can be used to send a wild card label withdrawals to remote LSRs upon physical port failure. VC ID A non-zero 32-bit connection ID that together with the VC type, identifying VC for which label is being provided. Interface parameters A variable length field that is used to provide interface specific parameters of the egress interface of the VC. Format of this field is described in section 5.1 of [2]. Interface parameter field MAY be present even if no special parameters were requested in the corresponding LABEL REQUEST object. Total length of this field MUST be multiple of 4 and if necessary it MUST be padded with zeroes to the nearest 32-bit boundary. VC LABEL Generic MPLS label encoded right aligned in 4 octets. Note that ATM and Frame Relay labels cannot be used in this context. VC LABEL REQUEST Object The VC LABEL REQUEST object MAY be used in RSVP PATH messages to request label mapping for a particular VC from the egress LSR. The VC LABEL REQUEST object SHOULD be interpreted only by the egress LSR whose router ID is the tunnel end point IP address in the Session object of the RSVP PATH message. (This requirement is of interest primarily for the direct- VC method.) Multiple VC LABEL REQUEST objects MAY be present in one PATH message. If multiple LABEL REQUEST objects with identical VC ID are present only the first one MUST be used while others MUST be ignored and notification to management SHOULD be generated. The VC LABEL REQUEST class number is 209 (see sect. 9) and currently only C-Type 1 is defined. The VC LABEL REQUEST object is optional from RSVP point of view. Based on rules in Section 3.10 of [4] all LSRs that do not support this class MUST ignore it and pass it unchanged. LSRs supporting VC LABEL REQUEST class MUST also support VC LABEL class. Cai, et. al. Expires April, 2002 Page 8 Internet Draft VC-RSVP-TE Nov., 2001 The VC LABEL REQUEST object has following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |C| VC TYPE |VC Info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Field MUST be zeroed on transmission and ignored on receipt. VC TYPE A 15-bit quantity containing a value which represents the type of VC. Assigned Values are: VC Type Description 0x0001 Frame Relay DLCI 0x0002 ATM AAL5 VCC transport 0x0003 ATM transparent cell transport 0x0004 Ethernet VLAN 0x0005 Ethernet 0x0006 HDLC ( Cisco ) 0x0007 PPP 0x8008 CEM [8] 0x0009 ATM VCC cell transport 0x000A ATM VPC cell transport 0x000B MPLS Control word bit (C) The C bit is used to signal whether control word (as defined in [5]) will be used for the VC. C bit = 1 control word present on this VC. C bit = 0 no control word present on this VC. VC information length Length of the VC ID field and the interface parameters field in octets. If this value is 0, then it references all VCs using the specified group Cai, et. al. Expires April, 2002 Page 9 Internet Draft VC-RSVP-TE Nov., 2001 ID and there is no VC ID present, nor any interface parameters. The length must be multiple of 4. Group ID An arbitrary 32 bit value which represents a group of VCs that is used to augment the VC space. This value MUST be user configurable. The group ID is intended to be used as a port index, or a virtual tunnel index. To simplify configuration a particular VC ID at ingress could be part of the virtual tunnel for transport to the egress router. The Group ID is very useful to send a wild card label withdrawals to remote LSRs upon physical port failure. VC ID A non-zero 32-bit connection ID that together with the VC type, identifying VC for which label is being provided. Interface parameters Variable length field is used to provide interface specific parameters of the ingress interface of the VC. Format of this field is described in section 5.1 of [2]. Interface parameter field MAY be present even if no special parameters were requested in corresponding LABEL REQUEST object. Total length of this field MUST be multiple of 4 and if necessary it MUST be padded with zeroes to the nearest 32-bit boundary. Processing Rules Ingress To request VC label for a particular virtual circuit, the ingress of L2 tunnel places VC LABEL REQUEST objects with appropriate VC Type in RSVP PATH messages and sends them to the egress. VC Label Request objects SHOULD be placed immediately after LABEL REQUEST objects in the PATH message. The ingress node SHOULD set the C bit in the VC LABEL REQUEST object if it intends to use the control word in the encapsulation of L2 PDUs. The ingress node MUST NOT send data over the L2 circuit if: - The egress node does not reply with a VC LABEL object, - The VC LABEL object has C bit set and the LSR is not capable of supporting control word in the encapsulation, - Interface parameters specified in the VC LABEL object are not acceptable, or - Interface parameters specified in VC LABEL REQUEST object are not found in the corresponding VC LABEL object. The ingress node SHOULD stop sending VC LABEL REQUEST objects in RSVP PATH messages if it detects that the egress node of the L2 channel is not operational. Cai, et. al. Expires April, 2002 Page 10 Internet Draft VC-RSVP-TE Nov., 2001 If the ingress does not receive RESV replies with VC LABEL objects from the egress after certain timeout period, it SHOULD use methods appropriate in the L2 protocol to signal that the receiving side of the virtual circuit is not operational. The signal SHOULD be sent to the L2 link that is being tunneled over MPLS network. If the ingress wants to change the VC setup, it simply sends revised VC LABEL REQUEST objects in PATH messages. The virtual circuit that does not have the corresponding VC ID in the revised VC LABEL REQUEST object SHOULD be torn down. If the ingress wants to tear down a particular virtual circuit it MUST stop sending VC Label Request object in PATH messages. Alternatively it MAY also initiate the teardown procedure as defined in [4]. In direct-VC mode the label to be used for the VC is the one received in the LABEL object. In tunneled-VC mode the label to be used for the VC is the one received in the VC LABEL object. Egress The egress node replies to VC LABEL REQUEST objects in PATH messages with VC LABEL objects in RESV messages. The egress node MUST NOT reply with VC LABEL object if: - The VC Type specified in the VC Label Request is not supported, - The specified VC ID does not match any configured virtual circuit, - The VC Label Request object has the C bit set and the egress LSR is not capable of using control word in L2 PDU encapsulation, - Interface parameters specified in the VC LABEL REQUEST object are not acceptable, or, - The receiving side of the L2 circuit related to the VC ID is not operational. The egress node MAY set the C bit to 1 in VC Label object if it requires the ingress node to use the control word in the encapsulation. This may occur even if the VC Label Request object that has C bit set to zero. If interface parameter field is included in the VC LABEL REQUEST, egress LSR MUST include this field unchanged in the VC LABEL object. It MAY include interface parameter field in the VC LABEL object even if no such field was present in the corresponding VC LABEL REQUEST. If egress does not receive PATH messages with VC LABEL REQUEST objects after certain timeout period, it SHOULD use methods appropriate for the L2 protocol to signal that the sending side of the virtual circuit is not operational. The signal should be sent on the L2 link that is being tunneled over MPLS network. If egress wants to change the VC setup, it simply sends revised VC LABEL objects in RESV messages. Cai, et. al. Expires April, 2002 Page 11 Internet Draft VC-RSVP-TE Nov., 2001 If egress wants to tear down a particular VC of L2 it MUST stop replying to the corresponding VC Label Requests. Alternatively it MAY also initiate the teardown procedure as defined [4]. 6. Scalability The scalability of RSVP-TE greatly improves when implementing the RSVP refresh-overhead reduction scheme described in [6]. [6] defines extensions for RSVP that drastically reduce the overhead of the refresh messages of the protocol, as long as the information delivered in them is not new. The extensions also improve the overhead and latency of delivery of new information by the protocol. This improves the scalability of the RSVP protocol to a level that is similar to that of LDP. Since this draft adds new objects to be signaled, the refresh reduction scheme should be enhanced to support unknown objects. See details below. We have illustrated two possible modes that may be implemented. In the direct-VC mode, each VC is implemented by an LSP of its own, and in the tunnel-VC mode, VCs are aggregated into fewer LSPs. The direct-VC mode one is less scaleable, but is simpler and provides finer control of QoS of individual VCs. The tunnel-VC mode provides better scalability. In either mode, or in the hybrid mode, aggregation of VCs into LSPs should be performed using the technique described in [7]. This draft [7] suggests using the label-stacking capability of MPLS to allow an LSP to behave as a single hop for LSPs that flow through it. This enables using a single LSP to carry a number of VCs flowing between the same two PE devices. According to [7], signaling of the nested VCs should be performed by sending the signaling messages nested in the aggregating LSP. The draft also discusses the issue of sending signaling messages back, which might be an issue since the LSP is unidirectional and therefore cannot be used for sending messages in the reverse direction. The draft states three different options for doing that: using an LSP in the reverse direction, if exists; unicasting them back to the head-end of the LSP along the control path; or encapsulate these messages with an another IP-header with destination-address being the address of the head- end of the LSP. Please observe that actually, each of these techniques can be used in the LSP direction as well. These techniques should be used to ensure that intermediate LSRs do not take part in the signaling of the VCs, and therefore greatly increase scalability in terms of memory, processing-power at intermediate nodes, and reaction-time of the VC creation and deletion and of LSP rerouting. [7] also discusses forming a forwarding adjacency out of the LSP, by advertising the LSP as a link into ISIS/OSPF. This is less relevant for our purposes, although it can be used. Cai, et. al. Expires April, 2002 Page 12 Internet Draft VC-RSVP-TE Nov., 2001 7. Refresh-Reduction Considerations RSVP Refresh Overhead Reduction Extensions [6] can be used to reduce the processing overhead of RSVP refresh messages and improve the scalability of RSVP. However [6] does not specify how refresh reduction capable nodes should handle newly defined RSVP objects that are unknown to existing implementation. While Bundle messages are unaffected by unknown objects, the implementation needs to compare unknown objects before sending out Srefresh messages. In a manner of section 3.10 of RSVP [4], the extension below clarifies the handling of unknown objects and defines four possible ways that an RSVP Refresh Reduction implementation can treat an object of unknown class ('b' represents a bit with either 0 or 1): o Class-Num = 0bbbbbbb According to [4], the entire RSVP message with this unknown object should be rejected and an "Unknown Object Class" error should be returned. Thus, such unknown objects should not be of concern to any Refresh Reduction implementation. o Class-Num = 10bbbbbb The node should ignore the object, and for the purpose of comparison with previous object, the node should consider it the same and should not send a trigger message because of this object. o Class-Num = 110bbbbbb, 1110bbbb For the purpose of comparison, the node should consider this object as different from previous objects and send a trigger message instead of a refresh message. Note in this case, refresh reduction techniques does not apply and standard RSVP refresh messages have to be used. o Class-Num = 1111bbbb The node should include an MESSAGE_ID object in the RSVP message that propagates this object to the next hop and set the ACK_Desired flag in the MESSAGE_ID object. When such message is acknowledged by the MESSAGE_ID_ACK object, the node should delete such objects from its internal state. This behavior utilizes the reliable delivery mechanism of RSVP Refresh Reduction RFC and it is especially suitable to end-to-end objects that intermediate nodes need not to be aware of except delivering to the end node. As defined in previous sections, the VC Label Request Object and the VC Label Object has class number 240 and 241 with leading four bits equal to 1111. With the extension above, the intermediate nodes should delete VC objects after delivering the objects to the next hop. Thus, these objects adds very little overhead to the intermediate nodes. Cai, et. al. Expires April, 2002 Page 13 Internet Draft VC-RSVP-TE Nov., 2001 8. Membership discovery RSVP-TE works in downstream on-demand mode, making it impossible to advertise VPN-membership using the signaling protocol. This means that the VPN-membership data should be delivered by other means. There are many solutions to this issue. In many networks, membership is explicitly configured at the edges. Another solution can be to use a database accessible by the PE devices to centrally hold the VPN- membership data. A popular scheme is to advertise VPN-membership using BGP. With the BGP solution, one variation is to advertise the labels using BGP, in which case signaling of VCs is not required. Another mode is to advertise only VPN-membership using BGP and still signal the VCs for label and QoS parameters exchange. 9. Security Considerations This document does not affect the underlying security issues of MPLS. This draft does not introduce any security considerations related to RSVP-TE that are not already part of the existing usage for LSPs. 10. IANA Considerations The RSVP class number 208 and 209 and their C-Types is pending IANA approval. This draft requires no further IANA actions. 11. Authors' Addresses Martin Machacek Terabeam Networks, Inc. 14833 NE 87th St. Redmond, WA, USA Martin.Machacek@Terabeam.com Ting Cai Terabeam Networks, Inc. 14833 NE 87th St. Redmond, WA, USA (206) 321-6367 Ting.Cai@terabeam.com Pascal Menezes Terabeam Networks, Inc. 14833 NE 87th St. Redmond, WA, USA (206) 686-2001 Cai, et. al. Expires April, 2002 Page 14 Internet Draft VC-RSVP-TE Nov., 2001 Pascal.Menezes@Terabeam.com Lior Shabtay Atrica, Inc. 5 Shenkar St. Hertzeliya, Israel Lior_Shabtay@atrica.com Marty Borden Atrica, Inc. 30 Shaker Lane Littleton, MA 01460 mborden@atrica.com Acknowledgments We would like to thank Jeff Apple for reviewing the draft and Steve Cheek and Karel Zikan for their just-in-time help on editing the draft. References 1 S. Bradner, BCP 14, RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 2 L. Martini, et. al., "Transport of Layer 2 Frames Over MPLS", draft- martini-l2circuit-trans-mpls-07.txt, Work in Progress. 3 D. O. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," draft-ietf-mpls-rsvp- lsp-tunnel-09.txt (To be reissued as a Proposed Standard RFC) 4 R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, RFC 2205, "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification", September, 1997 5 L. Martini, et. al., "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-encap-mpls-03.txt, Work in Progress 6 L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasiand, S. Molendini, RFC 2961, "RSVP Refresh Overhead Reduction Extensions", April 2001. 7 K. Kompella, Y. Rekhter, "LSP Hierarchy with MPLS TE", draft-ietf- mpls-lsp-hierarchy-02.txt, Work in Progress. Cai, et. al. Expires April, 2002 Page 15 Internet Draft VC-RSVP-TE Nov., 2001 8 D. O. Awduche, A. Hannan, X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels,"draft-ietf-mpls-rsvp-tunnel- applicability-02.txt. (To be reissued as an Informational RFC) 9 P. Pan, Y. Rekhter, K. Kompella, F. Liaw, D. Pandarakis, G. Swallow, J. Drake, "Graceful Restart Mechanism for RSVP-TE", draft-pan-rsvp- te-restart-01.txt, Work in Progress. 10 A. Farrel, P. Brittain, P. Matthews, E. Gray, "Fault Tolerance for LDP and CR-LDP", draft-ietf-mpls-ldp-ft-02.txt, Work in Progress. 11 M. Leelanivas, Y. Rekhter, R. Aggarwal, "Graceful Restart Mechanism for LDP", draft-leelanivas-ldp-restart-01.txt, Work in Progress. Cai, et. al. Expires April, 2002 Page 16