[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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


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).


   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

   We provide answers to these questions below in sections 2 and 3

    +---+                     +---+                     +---+
    |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

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

   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

   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]