Internet Draft

Internet Draft                                           June 1st, 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-katsube-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 Dec. 1997                   [Page  1]

Internet Draft    draft-katsube-mpls-over-svc-00.txt          June 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 Dec. 1997                   [Page  2]

Internet Draft    draft-katsube-mpls-over-svc-00.txt         June 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 Dec. 1997                   [Page  3]

Internet Draft     draft-katsube-mpls-over-svc-00.txt         June 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 Dec. 1997                   [Page  4]

Internet Draft     draft-katsube-mpls-over-svc-00.txt         June 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 Dec. 1997                   [Page  5]

Internet Draft     draft-katsube-mpls-over-svc-00.txt         June 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 Dec. 1997                   [Page  6]

Internet Draft      draft-katsube-mpls-over-svc-00.txt        June 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 Dec. 1997                    [Page  7]