Network Working Group Noritoshi Demizu Internet Draft SonyCSL Expiration Date: February 1998 September 1997 VC-ID, VC Pool, and ATM SVC Support for ATM-LSRs 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Several label switching schemes have been proposed to fuse and integrate the cost-performance and QoS assurance of Layer 2 devices and the flexibility and functionality of Layer 3 protocols. Some of these proposals assume that Label Switching Routers (LSRs) are placed in a homogeneous LSR cloud in a campus area network or a backbone network, and they are permanently connected directly to each other without intermittent connections. However, this assumption sometimes does not hold true in the real situation. For example, some of campuses will be connected via ATM SVC services, and LSR networks will be constructed hierarchically. Furthermore, LSR networks will consist of heterogeneous datalinks such as ATM, Ethernet, and IEEE 1394. To deal with Virtual Connections (VCs) in these environments, this document proposes VC-ID and VC pool. This document also proposes procedures to deal with ATM SVC services in ATM-LSRs. Demizu [Page 1] Internet Draft draft-demizu-mpls-vcid-00.txt September 1997 1. Introduction Several label switching schemes[ARIS][RFC2098][RFC1953][RFC2105] have been proposed to fuse and integrate the cost-performance and QoS assurance of Layer 2 (L2) devices and the flexibility and functionality of Layer 3 (L3) protocols. Some of these proposals assume that Label Switching Routers (LSRs) are placed in a homogeneous LSR cloud in a campus area network or a backbone network, and they are permanently connected directly each other without intermittent connections. This assumption leads some proposed label distribution protocols (LDPs) [ARISP][RFC1953][TDP] to assume that an input label at an ingress node and the corresponding output label at an egress node of each Virtual Connections (VC) are always the same. However, in real situation, campuses will be connected via ATM VP, PVC, SVC, etc., and LSRs inside campuses may need to use existing ATM LANs such as LANE[LANE] as their underlying datalinks. Furthermore, it will be common to construct LSR networks hierarchically, and some LSR networks will use other LSR networks for their underlying networks[INT_LSP]. In this case, higher level LSRs should use Label Switched Paths (LSPs) traversing lower level LSRs, that may obey other schemes. Even L2 networks could be designed by applying label switching technology and could constitute hierarchical label switching networks at the bottom level[ARISLAN][PLASMA]. Moreover, hierarchical LSR networks will be constructed with heterogeneous datalinks such as ATM, Ethernet, and IEEE 1394. In these environments, a label often cannot be used as an identifier of a VC or an LSP (both will be denoted as a VC in this document), because it is very difficult to set up labels such that an input label at an originating node and the corresponding output label at a terminating node are always the same. Furthermore, certain types of VCs including ATM SVC require signaling to establish VCs before employing them and to release VCs after utilizing them. Because signaling may take long time and carriers may charge each VC establishment, connection time and/or the amount of traffic, some kind of optimization is necessary to reduce the delays and the costs of signaling. To solve these problems, this document proposes to identify a VC with a VC-ID, which is independent from datalink specific information such as a label, and to introduce a VC pool to reduce the delays and the costs of VC establishment due to signaling. This document also proposes procedures to deal with ATM SVC services in ATM-LSRs. Demizu [Page 2] Internet Draft draft-demizu-mpls-vcid-00.txt September 1997 2. VC-ID Proposal To identify a VC between peer LSRs that are separated by L2 switches, this document proposes to introduce a new VC identifier called VC-ID to be used instead of a label such as VPI/VCI to identify a VC. VC- ID is significant between peer LSRs on the same hierarchical level. The value of a VC-ID is conceptually independent from the value of the label or any other datalink specific information of the VC. The length and the range of VC-ID would vary for each LDP and may be constrained by an environment where each LSR runs. In this document, a label is re-defined as a short fixed length physically contiguous index that specifies where and how the cells or frames should be forwarded by layers lower than L3. A VC-ID value for a VC should be significant between peer LSRs. In the case where peer LSRs are connected directly, it is easy to achieve this by using the label value as the VC-ID value. However, in other cases, peer LSRs have to communicate with each other to determine a VC-ID value for each VC. The notification may be performed by either using an extended LDP, a supplementary protocol or a signaling protocol used by the datalink. The details of this communication procedure depend on each LDP and underlying network, and is out of the scope of this document. Note that this notification that determines the VC-ID value does not introduce any conflict to current schemes. 3. VC Pool Proposal A VC pool is where a number of VCs is prepared a priori. VCs can be picked immediately from the VC pool on BIND procedures and will be put back to the VC pool on UNBIND procedures. So, VCs can be recycled without unnecessary signaling. If there are too many VCs in a VC pool, some of them may be released to reduce the costs to maintain these VCs. Each established VC in a VC pool should be associated with a VC-ID, because it is sometimes impossible to use datalink specific information as an identifier for a VC in a VC pool due to its small range. However, the association between a VC and a VC-ID can be postponed until the VC will be used if protocol optimization is necessary. An LSR may have multiple VC pools for each VC class. Examples of VC classes are UBR VCs, CBR VCs, point-to-multipoint VCs, etc. The advantages of VC pool are: Demizu [Page 3] Internet Draft draft-demizu-mpls-vcid-00.txt September 1997 - It is possible to reduce delays and costs of signaling. - It hides the details of signaling procedures of each datalink from LDPs. - It becomes easy to use both directions of bi-directional VCs such as ATM SVC with a VC pool, because each direction of a VC can be used independently. Note that the idea of VC pool does not conflict with current implementations that do not have a VC pool, because they can be considered to have a special case of VC pool, where all VCs are prepared a priori and there is no need to establish VCs nor to release VCs. Also note that VC pool can be applied to intermittent datalinks other than ATM. 4. ATM SVC Support for ATM-LSRs 4.1 ATM Forum Signaling The ATM Forum defines a signaling protocol to set up SVCs. In this document, it is called "ATM Forum Signaling". Callers can transfer out-of-band information to callees by the ATM Forum Signaling. BLLI is one of information that must be transferred and is a user specific 7 bit field in the L3 protocol field in the BLLI IE (Broadband Low Layer Information, Information Element). When a new VC is established by ATM Forum Signaling, the callee can read the BLLI value and caller's ATM address of the VC. In the proposal of this document, the BLLI value is used as a temporary identifier for a VC during VC-ID notification procedure. So the BLLI value of a new VC should not be assigned for other VCs during the procedure to avoid conflicts. After the association of the VC having the BLLI value to a VC-ID has been completed, the BLLI value of the new VC can be assigned to other VCs. VC-ID values can be assigned independently from BLLI values. A point-to-multipoint VC can also be established by using ADD_PARTY of ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an existing VC or an existing VC tree and makes a point-to-multipoint VC tree as a result. In this procedure, the BLLI value of ADD_PARTY should be the same value as that was used to establish the first point-to-point VC of the tree. However, different VC trees can use the same BLLI value without any conflicts between them if VC trees that use the same BLLI value do not establish VCs nor add VCs simultaneously. So the BLLI value used for signaling should be determined by the root node of multicast tree for consistency. Demizu [Page 4] Internet Draft draft-demizu-mpls-vcid-00.txt September 1997 There can be another method to exchange identity information of VCs between neighboring LSRs. For example, a caller can send an in-band control message to a callee over the established new VC in order to notify the identity information of the VC. This method works well in the unicast case, but causes a problem in multicast. The caller needs to temporarily splice the active VC each time a new leaf LSR joins the multicast tree in order to send such in-band messages to the leaf. This will cause serious degradation in the performance at the LSR. Otherwise, we should mandate non-interleaving switching fabric for the LSR. So this document does not employ this method. The remaining part of this section describes procedures to notify a VC-ID between a caller and a callee. Detailed procedures should be defined for each label distribution protocol. How to get the ATM address of a callee at a caller is out of the scope of this document. 4.2 Support for Unicast Traffic This section proposes procedures to establish a VC and to notify its VC-ID between neighboring LSRs for unicast traffic. This document proposes following procedures, for when an upstream LSR allocates a VC-ID for a new VC. 0. In the case where a downstream LSR starts to prepare a VC in the VC pool, the downstream LSR sends a VC establishment request message to its upstream LSR. Otherwise, skip step 0. 1. An upstream LSR establishes a VC by ATM Forum Signaling between the downstream LSR with a unique BLLI value at this moment. (If the association between the VC and a VC-ID should be postponed until the VC starts to be used, resume here.) 2. The upstream LSR notifies a pair of the BLLI value and a VC-ID to the downstream LSR by using a message dedicated for this purpose or together within a BIND message. 3. The downstream LSR associates the VC having the BLLI value with the VC-ID, and sends an ACK message to the upstream LSR. If the VC-ID is used by some other VC between the upstream, the old VC is discarded. 4. After the upstream LSR receives the ACK message, it associates the VC with the VC-ID. The VC is ready to be used at this step, and the BLLI value that was allocated to the VC can be re-used for another VC. This document proposes following procedures for when a downstream LSR allocates a VC-ID for a new VC. Demizu [Page 5] Internet Draft draft-demizu-mpls-vcid-00.txt September 1997 0. In the case where a downstream LSR starts to prepare a VC in the VC pool, the downstream LSR sends a VC establishment request message to its upstream LSR. Otherwise, skip step 0. 1. An upstream LSR establishes a VC by ATM Forum Signaling between the downstream LSR with a unique BLLI value at this moment. (If the association between the VC and a VC-ID should be postponed until the VC starts to be used, resume here.) 2. The downstream LSR notifies a pair of the BLLI value and a VC-ID to the upstream LSR by using a message dedicated for this purpose or together within a BIND message. 3. The upstream LSR associates the VC having the BLLI value with the VC-ID, and sends an ACK message to the downstream LSR. If the VC-ID is used by some other VC between the downstream, the old VC is discarded. 4. After the downstream LSR receives the ACK message, it associates the VC with the VC-ID. The VC is ready to be used at this step, and the BLLI value that was allocated to the VC can be re-used for other VC. 4.3 Support for Multicast Traffic This section proposes procedures to establish the first VC for a multicast stream and to add a new VC leaf to an existing VC tree including the notification of its VC-ID for a multicast stream by using point-to-multipoint VCs. In this proposal, an upstream LSR determines both VC-ID and BLLI value in the multicast case. The reason the BLLI value is determined by an upstream LSR is described in Section 4.1. Since it is difficult to recycle point-to-multipoint VCs, the VC pool is not used for multicast. This document proposes the following procedure to establish the first VC. 1. An upstream LSR establishes a VC by ATM Forum Signaling between the downstream LSR with a unique BLLI value at this moment. 2. The upstream LSR notifies a pair of the BLLI value and a VC-ID to the downstream LSR by using a message dedicated for this purpose or together within a BIND message. 3. The downstream LSR associates the VC having the BLLI value with the VC-ID, and sends an ACK message to the upstream LSR. If the VC-ID is used by some other VC between the upstream, the old VC is discarded. Demizu [Page 6] Internet Draft draft-demizu-mpls-vcid-00.txt September 1997 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. This document proposes the following procedure to establish the second VC or later. 1. The upstream LSR establishes a VC by 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. Goto step 2 of the procedure for the first VC. 4. Conclusion Label switching will be applied to various networks including backbone networks, campus area networks and home area networks. In these environments, LSR networks will be constructed hierarchically. However, hierarchical label switching has several issues to be solved in both vertical and horizontal directions. This document focuses on some issues in the vertical direction and proposes VC-ID and VC pool. The VC-ID makes it possible to identify a VC in any layer of the hierarchy, and the VC pool reduces the delays and the costs of establishing and releasing VCs and VC-ID notification. Both VC-ID and VC pool do not conflict with current schemes. This document also proposes procedures to use ATM SVCs from LSRs. This proposal hides the limitation from the range of BLLI and avoids modifications to the core messages of label distribution protocols. Security Considerations Security issues are not discussed in this document. Acknowledgments The author would like to acknowledge valuable technical comments from members of LAST-WG of WIDE Project, in particular from Kenichi Nagami, Hiroshi Esaki and Yasuhiro Katsube. The author also would like to thank Paul Doolan for his valuable technical comments. Demizu [Page 7] Internet Draft draft-demizu-mpls-vcid-00.txt September 1997 References [MPLSFW] R. Callon, et. al., "A Framework for Multiprotocol Label Switching", draft-ietf-mpls-framework-01.txt, Jul 1997 [ARIS] A. Viswanathan, et. al., "ARIS: Aggregate Route-Based IP Switching", draft-viswanathan-aris-overview-00.txt, Mar 1997 [ARISP] N. Feldman, A. Viswanathan, "ARIS Specification", draft-feldman-aris-spec-00.txt, Mar 1997 [RFC2098] Y. Katsube, et. al., "Toshiba's Router Architecture Extensions for ATM : Overview", RFC2098, Feb 1997 [RFC2129] K. Nagami, et. al., "Toshiba's Flow Attribute Notification Protocol (FANP) Specification", RFC2129, Apr 1997 [RFC1953] P. W. Edwards, et. al., "Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0", RFC1953, May 1996 [RFC2105] Y. Rekhter, et. al., "Cisco Systems' Tag Switching Architecture Overview", RFC2105, Feb 1997 [TDP] P. Doolan et. al., "Tag Distribution Protocol", draft-doolan-tdp-spec-01.txt, May 1997 [LANE] ATM Forum, "LAN Emulation over ATM Specification Ver.1.0", April, 1995. [PLASMA] K. Fujikawa, "Point-to-point Link Assembly for Simple Multiple Access (PLASMA)", draft-fujikawa-plasma-00.txt, Mar 1997 [ARISLAN] Steven Blake, et. al., "ARIS Support for LAN Media Switching", draft-blake-aris-lan-00.txt, Mar 1997 [INT_LSP] Y. Katsube, H. Esaki, "Interoperation Between Distinct Types of Label Switched Paths", draft-katsube-interop-between-lsps-00.txt, Jun 1997 [ATM_SVC] H. Esaki, et. al., "IP Address Resolution and ATM Signaling for MPLS over ATM SVC services" draft-katsube-mpls-over-svc-00.txt, Jun 1997 [TAG_ATM] B. Davie, et. al., "Use of Tag Switching With ATM" draft-davie-tag-switching-atm-01.txt, Jan 1997 Author Information Noritoshi Demizu Sony Computer Science Laboratory, Inc. Demizu [Page 8] Internet Draft draft-demizu-mpls-vcid-00.txt September 1997 Takanawa Muse Bldg. 3-14-13, Higashigotanda, Shinagawa-ku, Tokyo, 141 Japan Phone: +81-3-5448-4380 E-mail: demizu@csl.sony.co.jp Demizu [Page 9]