Internet Draft Internet Draft March 1997 H. Esaki (Toshiba Corp.) Y. Katsube (Toshiba Corp.) K. Nagami (Toshiba Corp.) P. Doolan (Cisco Systems Inc.) Y. Rekhter (Cisco Systems Inc.) IP Address Resolution and ATM Signaling for MPLS over ATM SVC services <draft-esaki-mpls-over-svc-00.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), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Enabling interconnection of ATM Label Switching Routers (ATM-LSRs) over standard ATM switch networks is desirable in order to introduce MPLS technology into emerging ATM-LAN/WAN platform. This draft describes how ATM-LSRs may interoperate with other ATM-LSRs over ATM UNI SVC services. The two aspects of the problem that we address are ATM address (of target ATM-LSR) resolution and SVC to label binding. 1. Introduction Several architectural models for label switching are proposed to the MPLS working group, e.g., [ARIS][RFC2098][RFC2105]. One of the major application of MPLS technology described in these proposals is ATM. Esaki, et al. Expires Sept. 1997 [Page 1] Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997 Interconnecting ATM-LSRs over point-to-point links is straight- forward since it is analogues to conventional ATM switch networks except for the difference in the control protocol (ATM-UNI/NNI control plane vs. MPLS specific control plane). It is possible to build "Hybrid" ATM-LSRs that operate in a "Ships in the night" mode running both MPLS and ATM Forum control planes on the same link [ATM_TAG]. It is also possible to interconnect ATM-LSRs over a cloud of standard ATM switches, which are non-MPLS ATM switches. Interconnecting ATM-LSRs over a cloud of standard ATM switches using VP services is described in [ATM_TAG]. In this case, the VCIs within the VP are the labels, and again the MPLS control plane can manage them similar to the point-to-point link case. This document describes operations of MPLS over ATM SVC networks. One possible circumstances where this might be necessary is ATM-LSRs interconnected through ATM switches that support ATM SVC services (e.g., ATM WAN cloud). Imagine two LSRs connected via such an ATM cloud. If one LSR decides, by normal L3 routing procedures, that it must forward traffic to the other, it opens an ATM SVC to that LSR. The question is "how does it obtain the ATM address of the target LSR to put in the SVC Setup?". When we answer this question, another immediately occurs: "when the SVC Setup arrives at the target LSR, how does that system know to which route or Forwarding Equivalence Class(FEC)[TAG_ARCH] this new SVC should be bound?". The diagram below shows a more general view of the application space. We provide answers to these questions below in sections 2 and 3 respectively. +---+ +---+ +---+ |LSR| +-----+ +-----+ |LSR| +-----+ +-----+ |LSR| -| |-|ATMSW|-...-|ATMSW|-| |-|ATMSW|-...-|ATMSW|-| |- +---+ +-----+ +-----+ +---+ +-----+ +-----+ +---+ <---------------------> <-------------------> standard ATM link standard ATM link <=========================================================> ATM cloud (or collections of ATM clouds) Fig.1 Label Switching Routers (LSRs) with standard ATM links Esaki, et al. Expires Sept. 1997 [Page 2] Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997 2 LSR ATM address selection An ATM-LSR, having made a determination that it must route traffic to another ATM-LSR, and finding, through some local procedure, that it must open an ATM SVC to that ATM-LSR must select an appropriate ATM address to place in the SVC Setup message. The selection of the address may be based on configuration or on dynamic resolution. In either case the ATM-LSR has, from its routing table, an IP address for which it requires a corresponding ATM address. 2.1 Configuration It is possible to provide tools and procedures to configure an ATM- LSR with, for example, IP to ATM address translation tables. The control mechanisms in the LSR that are responsible for deciding to setup SVCs could use these tables to obtain requisite ATM address for peer ATM-LSRs. This operation could be seen as the existing point-to-point link operation over SONET links, and it may become common for LSRs over WAN ATM links. 2.2 Dynamic resolution 2.2.1 Classical IP over ATM LSRs If the ATM-LSR is configured to be able to reach an RFC1577 ARP server and if the IP address of the target LSR is on the same subnet then the LSR may employ ATM-ARP [RFC1577] to attempt to resolve the ATM address of the target ATM-LSR. 2.2.2 NHRP capable LSRs If the ATM-LSR is able to reach an NHRP server, by configuration, anycast or MPOA LE_ARP discovery [MPOA], then it may use NHRP to attempt to resolve the ATM address of the target ATM-LSR. 3 Binding of ATM SVCs and MPLS labels When an ATM-LSR has decided to open an SVC to its neighbor ATM-LSR and has determined the appropriate ATM address using the procedures in section 2, it uses the mechanisms described here to communicate the 'binding' between the SVC and specific forwarding equivalence class(FEC)[TAG_ARCH]. The MPLS label value, which is VPI/VCI or VCI Esaki, et al. Expires Sept. 1997 [Page 3] Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997 in ATM, is not the same at both ends of an SVC. Therefore, neighboring ATM-LSRs, when they are communicating with each other, cannot use the label as an identifier of the SVC but should use another identifier that can be uniquely identified by both ends of the SVC. The binding between the unique identifier and the label is performed locally at individual ATM-LSRs. Basic mechanism of binding for SVC is to convey a unique identifier of an SVC in the BLLI IE of SETUP message, and to convey the identifier of the SVC in the MPLS binding request and/or acknowledge messages together with the specific FEC. Some example procedures are described below. 3.1 Support for Destination-based unicast routing over ATM SVCs Following the procedures outlined in [TAG_ATM], an ATM-LSR sends an MPLS message that request binding to its next-hop (downstream) ATM-LSR for the destination prefix contained in the request. The downstream ATM-LSR that receives the request provides a binding that contains an identifier that is unique between the upstream ATM-LSR. The upstream ATM-LSR, after it receives the binding sets up an SVC to the downstream ATM-LSR using the ATM Forum signalling procedures, which includes the received identifier in the BLLI field of the Setup message. The downstream LSR accepting the SVC setup is able to determine, from the identifier value in BLLI, the binding of this new SVC to the destination prefix. Another examples would be possible, e.g., SVC setup including unique identifier in the BLLI field may proceed the MPLS messages that exchange binding between the SVC (identified by the value at BLLI field) and the destination prefix. Whether the 7-bit BLLI space for the identifier is enough or not depends on up to when the identifier value should be held for a certain SVC, which further depends on the protocol to maintain or remove binding. For instance, if the removal of binding is performed by releasing the related SVC with a RELEASE message of ATM signaling, the unique identifier should be maintained only for the period between the time when the binding procedure begins and the binding has been established. 3.2 Support for multicast over ATM SVCs In the case that PIM-SM is used as a multicast routing protocol, following the procedures outlined in [TAG_PIM], an ATM-LSR sends PIM_Join messages to upstream neighboring ATM-LSRs toward the RP Esaki, et al. Expires Sept. 1997 [Page 4] Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997 for the shared-tree (*,G) or source for the source-tree (S,G). If the two ATM-LSRs are using SVC, the downstream LSR will include a unique identifier for an SVC, instead of label value, in the PIM Join message. When the upstream router receives the PIM Join, it will set up, using ATM signalling procedures, an SVC to the downstream ATM-LSR. The Upstream router sends the identifier it received in the PIM Join message in the BLLI IE of the SETUP message that it uses to establish the SVC. In this way the downstream ATM-LSR is able to associate the new SVC's label with the appropriate multicast tree. Once an SVC is setup for a group, subsequent PIM Join (refreshes) include the value zero in the identifier field. This special value indicates to the next hop router toward the RP that a SVC already exists and in this case that router simply refreshes its PIM state without initiating SVC setup. The identifier employed for this purpose is constrained by the available space in the BLLI to be 7 bits also. Whether this small space is enough or not depends on up to when the identifier value should be held for a certain SVC, which further depends on the protocol to maintain or remove binding. For instance, if the identifier is only of significance to the downstream LSR and only significant to it during the period between the dispatch of the PIM Join to the upstream router and the completion of the SVC setup, this is not a major restriction. Another examples, e.g., a multicast routing protocol other than PIM-SM is used, would be possible and added in later version of the draft. 4. Security Consideration Security considerations are not addressed in this memo. 5. References [ARIS] R.Woundy, A.Wiswanathan, N.Feldman, R.Biovie, "ARIS: Aggregated Route-Based IP Switching", draft-woundy-aris-ipswitching-00.txt, November, 1996. [FANP] K.Nagami, Y.Katsube, Y.Shobatake, A.Mogi, S.Matsuzawa, T.Jinmei, H.Esaki, "Flow Attribute Notification Protocol (FANP) Specification", draft-rfced-info-fanp-00.txt, December, 1996. [LANE] ATM Forum, "LAN Emulation over ATM Specification Ver.1.0", April, 1995. [MPOA] ATM Forum, "Multi Protocol Over ATM" (Work in Progress) Esaki, et al. Expires Sept. 1997 [Page 5] Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997 [NHRP] J.V.Luciani, D.Katz, D.Piscitello, B.Cole, "NBMA Next Hop Resolution Protocol (NHRP)", draft-ietf-rolc-nhrp-10.txt, October, 1996. [RFC1577] M.Laubach, "Classical IP and ARP over ATM", IETF RFC1577, October, 1993. [RFC1953] P.Newman, et al, "Ipsilon Flow Management Protocol Specification for IPv4 version 1.0", IETF RFC1953, May, 1996. [RFC2098] Y.Katsube, K.Nagami, H.Esaki, "Toshiba's Router Extensions for ATM", IETF RFC2098, February, 1997. [RFC2105] Y.Rekhter, B.Davie, D.Katz, E.Rosen, G.Swallow, "Cisco System's Tag Switching Overview", IETF RFC2105, February, 1997. [TAG_ARCH] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, D. Farinacci, "Tag Switching Architecture - Overview", draft-rekhter-tagswitch-arch-00.txt, Jan. 1997. [TAG_ATM] B Davie, P Doolan, J Lawrence, K McCloghrie, Yakov Rekhter, E Rosen, G Swallow, "Use of Tag Switching with ATM", draft-davie-tag-switching-atm-01.txt, Jan. 1997. [TAG_PIM] D. Farinacci, Y. Rekhter, "Multicast Tag Binding and Distribution using PIM", draft-farinacci-multicast-tagsw- 00.txt, Dec. 1996. [TDP] P.Doolan, B.Davie, D.Katz, Y.Rekhter, E.Rosen, "Tag Distribution Protocol", draft-doolan-tdp-spec-00.txt, September, 1996. 6. Authors Hiroshi Esaki Computer and Network Division, Toshiba Corporation, 1-1-1 Shibaura, Minato-ku, 105-01, Japan. Email: hiroshi@isl.rdc.toshiba.co.jp Yasuhiro Katsube R&D Center, Toshiba Corporation, 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Email: katsube@isl.rdc.toshiba.co.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 Esaki, et al. Expires Sept. 1997 [Page 6] Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997 Paul Doolan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 Email: pdoolan@cisco.com Yakov Rekhter Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 Email: yakov@cisco.com Esaki, et al. Expires Sept. 1997 [Page 7]