Internet Draft MPLS Working Group Ken-ichi Nagami (Toshiba Corp.) INTERNET DRAFT Noritoshi Demizu (NAIST) Hiroshi Esaki (Toshiba Corp.) Paul Doolan (Ennovate Networks) August 1998 Expires February 1999 VCID Notification over ATM link <draft-ietf-mpls-vcid-atm-01.txt> Status of this memo This document is an Internet-Draft. 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.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The ATM Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC may change on each VC of that VC, it is not possible to use them to identify a VC in label binding messages. The concept of Virtual Connection Identifier (VCID) is introduced to solve this problem. VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. 1. Introduction Several label switching schemes have been proposed to integrate Layer 2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one of the major applications of label switching. In the case of ATM VCs, the VPI and VCI labels are, in the general case, rewritten with new values at every switch node through which the VC passes and cannot be used to provide end to end identification of a VC. In the context of MPLS 'stream', which are classes of packets that have some common charachteristic that may be deduced by examination of the layer 3 header in the packets, are bound to layer 2 'labels'. We speak of stream being 'bound' to labels. These bindings are conveyed between peer LSRs by means of a Label Distribution Protocol [LDP]. In order to apply MPLS to ATM links, we need some way to identify ATM VCs in LDP binding messages. In [VCID], an identifier called a Virtual Connection ID (VCID) is introduced. VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. 2. Overview of VCID Notification Procedures 2.1 VCID Notification procedures The ATM has several types of VCs (transparent point-to-point link/VP/PVC/SVC). A transparent point-to-point link is defined as one that has the same VPI/VCI label at both ends of a VC. For example, two nodes are directly connected (i.e., without intervening ATM switches) or are connected through a VP with the same VPI value at both ends of the VP. There are two broad categories of VCID notification procedures; inband and out of band. The categorisation refers to the connection over which the messages of the VCID notification procedure are forwarded. In the case of the inband procedures, those messages are forwarded over the VC to which they refer. In contrast the out of band procedures transmit the messages over some other connection (than the VC to which they refer). We list below the various types of link and briefly mention the VCID notification procedures employed and the rational for that choice. The procedures themselves are discussed in detail in later sections. Transparent point-to-point link : no VCID notification VCID notification procedure is not necessary because the label (i.e., VPI/VCI) is the same at each end of the VC. VP : inband notification (as a default mechanism) - Inband notification VCID notification is needed because the VPI at each end of the VC may not be the same. Inband VCID notification [VCID] is used in this case. - No notification If a node has only one VP to a neighboring node, VCID notification procedure is not mandatory. The VCI can be used as the VCID. This is because the VCI value is the same at each end of the VP. PVC : inband notification Inband VCID notification [VCID] is used in this case because the labels at each end of the VC may not be the same. SVC : there are three possibilities - Out of band notification If a signaling message has a field which is large enough to carry a VCID value (e.g., GIT [GIT]), then the VCID is carried directly in it. - Outband notification using a small-sized field If a signaling message has a field which is not large enough to carry a VCID value, this procedure is used. - Inband notification If a signaling message can not carry user information, this procedure is used. When an LSP is a point-to-multipoint VC and an ATM switch in an LSR is not capable of VC merge, it may cause problems in performance and quality of service. When the LSR wants to add a new leaf to the LSP, it needs to split the active LSP temporarily to send an inband notification message. 2.2 VCID Assignment A VCID value is assigned by either an upstream node or a downstream node depending on the type of VC. For a point-to-point VC, either the upstream node or the downstream node could assign a VCID value. For a point-to-multipoint VC, only an upstream (root) node can assign a VCID value. 3. VCID Notification Procedures 3.1 Inband Notification Procedures 3.1.1 Inband Notification for Point-to-point VC VCID notification is performed by transmitting a control message through the VC newly established (by signalling or management) for use as an label switched path (LSP) [FRAME], The procedure for VCID notification between two nodes A and B is detailed below. 0. Node A establishes a VC to the destination LSR B. (by signalling or management) 1. Node A selects a VCID value. 2. Node A sends a message which contains the VCID value through the newly established VC to Node B. 3. Node A establishes an association between the outgoing label (VPI/VCI) for the VC and the VCID value. 4. Node B receives the message from the VC and establishes an association between the VCID in the message and the incomming label(VPI/VCI) for the VC. 5. Node B sends an ACK message to node A. 6. After Node A receives the ACK message, node A and node B both associate the VCID with the same VC. Node A Node B | | |--------------->| | VCID | | | |<---------------| | ACK | 3.1.2 Inband notification for point-to-multipoint VC VCID notification is performed by sending a control message through the VC to be used as an LSP. The upstream node must assign the VCID value. The procedure by which it notifies the downstream node of that value is given below. The procedure is used when a new VC is created or a new leaf is added to the VC. First, the procedure for establishing the first VC is described. 1. The upstream node assigns a VCID value for the VC. When the VCID value is already assigned to a VC, it is used for VCID. 2. The upstream node sends a message which contains the VCID value and the address of the upstream node through the VC used for a label switched path. This message is transferred to all leaf nodes. 3. The upstream node establishes an association between the outgoing label for the VC and the VCID value. 4. The downstream nodes receiving the message check the address of the upstream node. If the address is not the same network prefix as its address, the message is discarded. Otherwise, the downstream nodes establish an association between the VCID in the message and the VC from which the message is received. 5. The downstream nodes send an ACK message to the upstream node. 6. After the upstream node receives the ACK messages, the upstream node and the downstream nodes share the VCID. Upstream Downstream 1 Downstream 2 | | | |-----------+--->| | | VCID +------------------->| | | | |<---------------| | | ACK | | |<-------------------------------| | ACK | Second, the procedure for adding a leaf to the existing point-to-multipoint VC is described. 0. The upstream node adds the downstream node, using the ATM signaling. 1. The VCID value which already assigned to the VC is used. 2. The upstream node sends a message which contains the VCID value and the address of the upstream node through the VC used for a label switched path. This message is transferred to all leaf nodes. 3. The downstream nodes receiving the message check the address of the upstream node. If the address is not the same network prefix as its address, the message is discarded. Otherwise, the downstream nodes establish an association between the VCID in the message and the VC from which the message is received. 4. After the upstream node receives the ACK messages, the upstream node and the downstream nodes share the VCID. 3.2 Outband Notification using a small-sized field This method can be applied when a VC is established using an ATM signaling message and the message has a field which is not large enough to carry a VCID value. SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit mandatory field for the user. This is a user specific field in the Layer 3 protocol field in the BLLI IE (Broadband Low Layer Information Information Element). The BLLI value is used as a temporary identifier for a VC during a VCID notification procedure. This mechanism is defined as "Outband Notification using a small-sized field" described in [VCID]. The BLLI value of a new VC must not be assigned to other VCs during the procedure to avoid identifier conflict. When the association among the BLLI value, a VCID value, and the corresponding VC is established, the BLLI value can be reused for a new VC. VCID values can be assigned independently from BLLI values. Node A Node B | | |<-------------->| | ATM Signaling | | with BLLI | | | |--------------->| | BLLI & VCID | | | |<---------------| | ACK | A point-to-multipoint VC can also be established using ADD_PARTY of the ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an existing VC or an existing VC tree. In this procedure, the BLLI value of ADD_PARTY has to be the same value as that used to establish the first point-to-point VC of the tree. The same BLLI value can be used in different VC trees only when these VC trees can not add a leaf at the same time. As a result, the BLLI value used in the signaling must be determined by the root node of the multicast tree. [note] BLLI value is unique at the sender node. But BLLI value is not unique at the reciever node because multiple sender nodes may allocate the same BLLI value. So, the receiver node must recognize BLLI value and the sender address. ATM Signaling messages(SETUP and ADD_PARTY) carry both the BLLI and the sender ATM address. The receiver node can realize which node sends the BLLI message. 3.2.1 Outband notification using a small-sized field for point-to-point VC This subsection describes procedures for establishing a VC and for notification of its VCID between neighboring LSRs for unicast traffic. VC pool [VCPOOL] can be applied. For point-to-point VC, either an upstream LSR or a downstream LSR can allocate a VCID for a new VC. The procedure employed when the upstream LSR assigns a VCID is as follows. 1. An upstream LSR establishes a VC to the downstream LSR using ATM signaling and supplies a value in the BLLI field that it is not currently using for any other (incomplete) VCID notification transaction with this peer. 2. The upstream LSR notifies the downstream LSR of the association between the BLLI and VCID values. 3. The downstream LSR establishes the association between the VC with the BLLI value and the VCID and sends an ACK message to the upstream LSR. If the VCID is associated with some other VC between the upstream and downstream LSRs, that old VC is removed from service. 4. After the upstream LSR receives the ACK message, it establishes the association between the VC and the VCID. The VC is ready to be used. At this time the BLLI value employed in this transaction is free for reuse. The procedure employed when a downstream LSR assigns a VCID is as follows: 1. An upstream LSR establishes a VC by ATM signaling between the downstream LSR with a unique BLLI value at this time. 2. The downstream LSR notifies the upstream LSR of a paired BLLI value and VCID using a message dedicated for this purpose. 3. The upstream LSR establishes the association between the VC with the BLLI value and the VCID and sends an ACK message to the downstream LSR. If the VCID is associated with some other VC between the upstream and downstream LSRs, that old VC is removed from service. 4. After the downstream LSR receives the ACK message, it establishes the association between the VC and the VCID. The VC is ready to be used.At this time the BLLI value employed in this transaction is free for reuse. 3.2.2 Outband notification using a small-sized field for point-to-multipoint VC This subsection describes procedures for establishing the first VC for a multicast tree and for adding a new VC leaf to an existing VC tree including the notification of its VCID for a multicast stream using point-to-multipoint VCs. In this procedure, an upstream LSR determines both the VCID and BLLI value in the multicast case. The reason that the BLLI value is determined by an upstream LSR is described above. First, the procedure for establishing the first VC is described. 1. An upstream LSR establishes a VC by the ATM Forum Signaling between the downstream LSR with a unique BLLI value at this time. 2. The upstream LSR notifies the downstream LSR of a paired BLLI value and VCID using a message dedicated for this purpose. 3. The downstream LSR establishes the association between the VC with the BLLI value and the VCID and sends an ACK message to the upstream LSR. If the VCID is used by some other VC between the upstream and downstream LSRs, the old VC is discarded. 4. After the upstream LSR receives the ACK message, the VC is ready to be used and the BLLI value can be used for another VC. Second, the procedure for adding a leaf to the existing point-to-multipoint VC is described. 1. The upstream LSR establishes a VC by the ATM Forum Signaling between its downstream LSR with the BLLI value that was used during the first signaling procedure. If another VC is using the BLLI value at the same time, the upstream waits for the completion of the signaling procedure that is using this BLLI value. 2. Go to step 2 of the procedure for the first VC. 3.3 Outband notification This method can be applied when a VC is established using a ATM signaling message and the message has a field (e.g., GIT [GIT]) which is large enough to carry a VCID value. Message format is described in [GIT]. Node A Node B | | |<-------------->| | ATM Signaling | | with VCID | 4 VCID Message Format 4.1 VCID Class Messages VCID class messages are added to the LDP specification [LDP]. An LDP VCID PDU consists of an LDP common header followed by one or more objects. VCID PROPOSE inband message is sent as a null encapsulation packet through a VC to be used as an LSP. A label value in the label stack entry for VCID PROPOSE inband message is 4, that should be added as a reserved label value to the section 2.1 of [ENCAPS]. Other messages are sent as TCP packets. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Msg Class | PDU Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LDP Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Reserved | Msg Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Objects | | (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Objects | | (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version One octet unsigned integer containing the version number of the protocol. This version of the specification specifies protocol Version = 0x01. Msg Class One octet integer defining the class of the LDP message. VCID Class = 0x04 PDU Length Two octet integer specifying the total length of this PDU in bytes, excluding the common header. LDP Identifier Six octet field that uniquely identifiers the label space for which this PDU applies. The first four octets encode an IP address assigned to the LSR. This address should be the router- id, also used in LSR-path-vector loop detection/prevention objects. The last two octets identify a label space within the LSR. For a platform-wide label space, these should both be zero. Reserved This field is reserved. It must be set to zero on transmission and must be ignored on receipt. Msg Type The MsgType field identifies the type of message. The following discovery messages are supported: VCID Propose inband Message = 0x01 VCID Propose Message = 0x02 VCID ACK Message = 0x02 VCID NACK Message = 0x03 Msg Length Two octet integer specifying the total length of all objects associated with the message type. 4.1.1 VCID Propose inband Message This message is sent as a null encapsulation packet with a label value 4 through a VC to be used as an LSP. Mandatory Objects At least one of each mandatory object with associated object headers. +-----------------------+----------+ | MANDATORY OBJECT | Type | +-----------------------+----------+ | VCID | 0x01 | +-----------------------+----------+ | Address | 0x03 | +-----------------------+----------+ 4.1.2 VCID Propose Message Mandatory Objects At least one of each mandatory object with associated object headers. +-----------------------+----------+ | MANDATORY OBJECT | Type | +-----------------------+----------+ | VCID | 0x01 | +-----------------------+----------+ | Temporary ID | 0x02 | +-----------------------+----------+ 4.1.3 VCID ACK Message Mandatory Objects At least one of each mandatory object with associated object headers. +-----------------------+----------+ | MANDATORY OBJECT | Type | +-----------------------+----------+ | VCID | 0x01 | +-----------------------+----------+ 4.1.4 VCID NACK Message Mandatory Objects At least one of each mandatory object with associated object headers. +-----------------------+----------+ | MANDATORY OBJECT | Type | +-----------------------+----------+ | VCID | 0x01 | +-----------------------+----------+ 4.2 VCID Class Objects 4.2.1 Object Header All objects in a VCID message must begin with the following object header. This header is the same as LDP specification. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Obj Type | Sub Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Type VCID_OBJECT = 0x01 TEMPORARY_ID_OBJECT = 0x02 ADDRESS_OBJECT = 0x03 4.2.2 VCID Object +-----------------------+-------+--------------------------+----------+ | OBJECT | Type | Subtype(s) | Length | +-----------------------+-------+--------------------------+----------+ | VCID | 0x01 | 0x01 Default | 4 | +-------------------------------+--------------------------+----------+ Subtype = 0x01 Default 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.3 Temporary ID Object +-----------------------+-------+--------------------------+----------+ | OBJECT | Type | Subtype(s) | Length | +-----------------------+-------+--------------------------+----------+ | Temporary ID | 0x02 | 0x01 BLLI | 1 | +-------------------------------+--------------------------+----------+ Subtype = 0x01 Default 0 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+ | BLLI | +-+-+-+-+-+-+-+-+-+ 4.2.4 Address Object +-----------------------+-------+--------------------------+----------+ | OBJECT | Type | Subtype(s) | Length | +-----------------------+-------+--------------------------+----------+ | Address | 0x02 | 0x01 Default | variable | +-------------------------------+--------------------------+----------+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address List Family |Source Address (variable length) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family This 16 bit quantity contains a value from ADDRESS FAMILY NUM- BERS in Assigned Numbers [RFC1700] that encodes the address family that the network layer addresses in the Addresses field are from. Addresses Two addresses encoded according to the Address Family Field, padded to a 16-bit boundary. First address is a source address of this object. Second address is a destination address of this object. 4.3 Mapping messages 4.3.1 Label Object An VCID subtype is added to label object of an advertisment class message in the LDP specification. This object is used for a label mapping between SMD and VCID. +-----------------------+-------+--------------------------+----------+ | OBJECT | Type | Subtype(s) | Length | +-----------------------+-------+--------------------------+----------+ | Label | 0x03 | 0x03 VCID | 4 | +-------------------------------+--------------------------+----------+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Considerations Security issues are not discussed in this document. Intellectual Property Considerations Toshiba Corporation and Ennovate Networks may seek patent or other intellectual property protection for some of the aspects of the technology discussed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Toshiba Corporation, Toshiba intends to license them on reasonable and non- discriminatory terms. Acknowledgments The authors would like to acknowledge the valuable technical comments of Shigeo Matsuzawa, Akiyoshi Mogi, Yasuhiro Katsube, Muneyoshi Suzuki, George Swallow and members of the LAST-WG of the WIDE Project. References [VCID] N. Demizu, et al., "VCID: Virtual Connection Identifier", draft-demizu-mpls-vcid-01.txt, Oct. 1997 [VCPOOL] N. Demizu, et al., "VC pool", draft-demizu-mpls-vcpool-00.txt, Oct. 1997 [FRAME] R. Callon, et al., "A Framework for Multiprotocol Label Switching", draft-ietf-mpls-framework-02.txt, Nov. 1997 [GIT] M. Suzuki, "The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol", draft-ietf-mpls-git-uus-assignment-00.txt, June 1998 [ENCAPS] E. Rossen, et al., "MPLS Label Stack Encoding", draft-ietf-mpls-label-encaps-02.txt, July 1998 [rfc1700] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700, ISI, October 1994 Authors Information Ken-ichi Nagami R&D Center, Toshiba Corporation, 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Phone: +81-44-549-2231 Email: nagami@isl.rdc.toshiba.co.jp Noritoshi Demizu Graduate School of Information Science, Nara Institute of Science and Technology 8916-5 Takayama, Ikoma, Nara 630-0101, Japan Phone: +81-743-72-5348 E-mail: nori-d@is.aist-nara.ac.jp Hiroshi Esaki Computer and Network Division, Toshiba Corporation, 1-1-1 Shibaura, Minato-ku, 105-01, Japan Email: hiroshi@isl.rdc.toshiba.co.jp Paul Doolan Ennovate Networks 330 Codman Hill Road Boxborough, MA Phone: 978-263-2002 x103 Email: pdoolan@ennovatenetworks.com