Internet Draft Network Working Group Noritoshi Demizu (SonyCSL Inc.) Internet Draft Ken-ichi Nagami (Toshiba Corp.) Expiration Date: April 1998 Paul Doolan (Cisco Systems Inc.) Hiroshi Esaki (Toshiba Corp.) October 1997 VCID: Virtual Connection Identifier <draft-demizu-mpls-vcid-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 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 connected directly to each other. However, this assumption sometimes does not hold true in the real situation. For example, some campuses will be connected via ATM SVC service, and LSR networks will be constructed hierarchically. To deal with Virtual Connections (VCs) in these environments, this document proposes to identify a VC with a VCID instead of a label. 1. Introduction Demizu, et al. [Page 1] Internet Draft draft-demizu-mpls-vcid-01.txt October 1997 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 connected directly each other. This assumption leads some proposed label distribution protocols (LDPs) [ARISP][RFC1953][TDP] to assume that an input label at an ingress node of a Virtual Connections (VC) and the corresponding output label at an egress node of the VC are always the same. However, in real situation, some campus gateway LSRs will be connected via ATM VP, PVC, SVC, Frame Relay, etc., and LSRs inside campuses will be connected via ATM, IEEE 1394, etc. Furthermore, it will be common to construct LSR networks hierarchically, where higher level LSRs will treat Label Switched Paths (LSPs) traversing lower level LSRs as VCs of underlying networks. 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 ingress node of a VC and the corresponding output label at an egress node of the VC are always the same. To solve this problem, this document proposes to identify a VC with a VCID instead of a label. 2. Proposal of VCID To identify a VC between peer LSRs that are separated by L2 switches, this document proposes to introduce a new VC identifier called VCID to be used instead of a label such as VPI/VCI to identify a VC. VCID is significant only between peer LSRs on the same hierarchical level. The value of a VCID is conceptually independent from the value of the label or any other datalink specific information of the VC. The length and the range of VCID 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. This definition is different from the one in the MPLS framework document[MPLSFW] and MPLS Architecture document[MPLSARC], where a label is defined as an identifier of a stream. Demizu, et al. [Page 2] Internet Draft draft-demizu-mpls-vcid-01.txt October 1997 In other words, this document proposes to split the role of a label into a VC identifier and an index, and to use them properly. 3. VCID Value A VCID value for a VC should be the same 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 VCID value. It is also easy if an input label of a VC at an LSR and the corresponding output label of the VC at its peer LSR can be made always the same. However, in other cases, peer LSRs have to communicate with each other to determine a VCID value for each VC. The notification can be performed by either using an extended LDP, a supplementary protocol, or a signaling protocol used by the datalink. The notification methods can be categorized into following three: 1. Outband Notification 2. Outband Notification by using a small sized field 3. Inband Notification Brief explanation for each method follows this section. However, the details of this communication procedure depend on each LDP and datalink, and is out of the scope of this document. Note that this notification that determines the VCID value does not introduce any conflict to current schemes. 3.1. Outband Notification This method can be applied if a VC is established using a signaling message and the message has a field which is large enough to carry a VCID value. In this method, a VCID value is notified by using some field of a signaling message. The procedure is the following. A node establishes a VC using a signaling message. It carries a label value. In addition to this, a VCID value is carried in some field in the signaling message. (It depends on datalink which field is preferable to carry a VCID value.) If the signaling succeeds, nodes located each end of the VC can share the same VCID value for the VC and has a mapping between the VCID and the label. 3.2. Outband Notification by using a small sized field Demizu, et al. [Page 3] Internet Draft draft-demizu-mpls-vcid-01.txt October 1997 This method can be applied if a VC is established using a signaling message and the message has a field which is not large enough to carry a VCID value. In this method, at first a temporary identifier of a VC is notified by using some field of a signaling message. Then, the association of the temporary identifier and a VCID value is notified by using an LDP or a supplementary protocol. The procedure is the following. A node establishes a VC using a signaling message. It carries a label value. In addition to this, a temporary identifier is carried in some field in the signaling message. (It depends on datalink which field is preferable to carry a VCID value.) If the signaling succeeded, nodes located each end of the VC can share the same temporary identifier for the VC and has a mapping between the temporary identifier and the label. After that, the nodes exchange a mapping between the temporary identifier and a VCID value using an LDP message or a supplementary protocol. Then the nodes can share the same VCID value and have a mapping between the VCID and the label. 3.3. Inband Notification In this method, VCID is notified through an established new VC by using a control message of a supplementary protocol. The procedure is following. The message contains a VCID value. It is sent through the VC. A node sending the message has a mapping between the label for the VC and the VCID value in the message. A node receiving the message has a mapping between a label for the VC receiving the message and the VCID in the message. Both nodes can share the same VCID value for the VC. This method works well in a unicast LSP, but causes a problem in a multicast LSP and cell based datalink without VC merge switch. In that case, the sender needs to temporarily splice the active LSP 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. If we use a non-interleaving switching fabric for the LSR or flame based datalink, this problem does not occur. Security Considerations Security issues are not discussed in this document. Demizu, et al. [Page 4] Internet Draft draft-demizu-mpls-vcid-01.txt October 1997 Intellectual Property Considerations Toshiba Corporation 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 valuable technical comments from members of LAST-WG of WIDE Project. References [MPLSFW] R. Callon, et al., "A Framework for Multiprotocol Label Switching", draft-ietf-mpls-framework-01.txt, Jul 1997 [MPLSARC] E. Rosen, A Viswanathan, R. Callon, "A Proposed Architecture for MPLS", draft-rosen-mpls-arch-00.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 [INT_LSP] Y. Katsube, H. Esaki, "Interoperation Between Distinct Types of Label Switched Paths", draft-katsube-interop-between-lsps-00.txt, Jun 1997 Demizu, et al. [Page 5] Internet Draft draft-demizu-mpls-vcid-01.txt October 1997 Authors Information Noritoshi Demizu Sony Computer Science Laboratory, Inc. Takanawa Muse Bldg. 3-14-13, Higashigotanda, Shinagawa-ku, Tokyo, 141 Japan Phone: +81-3-5448-4380 E-mail: demizu@csl.sony.co.jp E-mail: nori-d@is.aist-nara.ac.jp Ken-ichi Nagami R&D Center, Toshiba Corporation, 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Email: nagami@isl.rdc.toshiba.co.jp Paul Doolan cisco Systems, Inc. 250 Apollo Drive. Chelmsford, MA 01824, USA Phone: +1-508-244-8917 email: pdoolan@cisco.com Hiroshi Esaki Computer and Network Division, Toshiba Corporation, 1-1-1 Shibaura, Minato-ku, 105-01, Japan Email: hiroshi@isl.rdc.toshiba.co.jp Demizu, et al. [Page 6]