Internet Draft Martin Machacek Document: draft-cai-vc-rsvp-te-00.txt Ting Cai Expires: August 2001 Terabeam Networks, Inc. February 2001 Signaling Virtual Circuit Label Using RSVP-TE Status of this Memo This document is an Internet-Draft and is in full conformance with 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 This document proposes an extension to RSVP-TE to distribute VC labels required by L2 circuit over MPLS encapsulation proposed by Martini et. al. The distribution of VC labels is piggybacked on signaling of LSP tunnels using two new RSVP objects. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................2 VC LABEL Object....................................................2 VC LABEL REQUEST Object............................................4 Processing Rules...................................................6 Security Considerations............................................7 Acknowledgements...................................................8 References.........................................................9 Author's Addresses.................................................9 Cai Internet Draft - Expires August 2001 1 Signaling Virtual Circuit Label Using RSVP-TE February 2001 Introduction 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. Martini et. al. proposed a method for distributing VC labels using LDP in downstream-unsolicited mode in [2]. We propose a simple extension to RSVP-TE [3] to signal VC labels using RSVP-TE in downstream-on-demand mode. 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 by the RSVP object format. This should simplify implementations supporting both LDP and RSVP-TE. 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]. 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 [Note] 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: 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 | | " | Cai Internet Draft - Expires August 2001 2 Signaling Virtual Circuit Label Using RSVP-TE February 2001 | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC LABEL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 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 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. Cai Internet Draft - Expires August 2001 3 Signaling Virtual Circuit Label Using RSVP-TE February 2001 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. 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 [Note] 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. 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 | | " | Cai Internet Draft - Expires August 2001 4 Signaling Virtual Circuit Label Using RSVP-TE February 2001 | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 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 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 Cai Internet Draft - Expires August 2001 5 Signaling Virtual Circuit Label Using RSVP-TE February 2001 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 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, - interface parameters specified in VC LABEL REQUEST object was not found in corresponding VC LABEL object. 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. If 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 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 corresponding VC ID in the revised VC LABEL REQUEST object SHOULD be torn down. Cai Internet Draft - Expires August 2001 6 Signaling Virtual Circuit Label Using RSVP-TE February 2001 If ingress wants to tear down a particular virtual circuit it SHOULD stop sending VC Label Request object in PATH messages. Alternatively it MAY also initiate the teardown procedure as defined in [4]. 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 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. - 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. If egress wants to tear down a particular VC of L2 it SHOULD stop replying to the corresponding VC Label Requests. Alternatively it MAY also initiate the teardown procedure as defined [4]. Security Considerations This document does not affect the underlying security issues of MPLS. Cai Internet Draft - Expires August 2001 7 Signaling Virtual Circuit Label Using RSVP-TE February 2001 Acknowledgements 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. Cai Internet Draft - Expires August 2001 8 Signaling Virtual Circuit Label Using RSVP-TE February 2001 References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 "Transport of Layer 2 Frames Over MPLS", draft-martini- l2circuit-trans-mpls-04.txt, Work in Progress. 3 "RSVP-TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp- lsp-tunnel-07.txt, Work in Progress. 4 RFC 2205 R. Branden, L.Zhang, S. Berson, S. Herzog, S. Jamin, "Resource Reservation Protococol (RSVP) -- Version 1 Functional Specification", September, 1997 5 "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-encap-mpls-01.txt, Work in Progress Note: The RSVP class number 208 and 209 and their C-Types is pending IANA approval. Author's Addresses Martin Machacek Terabeam Networks, Inc. 14833 NE 87th St. Phone: Redmond, WA, USA Email: Martin.Machacek@Terabeam.com Ting Cai Terabeam Networks, Inc. 14833 NE 87th St. Phone: (206) 321-6367 Redmond, WA, USA Email: Ting.Cai@terabeam.com Cai Internet Draft - Expires August 2001 9