home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_d_h / draft-demizu-mpls-atm-svc-00.txt < prev    next >
Text File  |  1997-10-07  |  13KB  |  335 lines
  1.  
  2. Network Working Group                    Noritoshi Demizu (SonyCSL Inc.)
  3. Internet Draft                           Ken-ichi Nagami (Toshiba Corp.)
  4. Expiration Date: April 1998             Paul Doolan (Cisco Systems Inc.)
  5.                                            Hiroshi Esaki (Toshiba Corp.)
  6.                                                             October 1997
  7.  
  8.  
  9.                       ATM SVC Support for ATM-LSRs
  10.                    <draft-demizu-mpls-atm-svc-00.txt>
  11.  
  12.  
  13. Status of this memo
  14.  
  15.      This document is an Internet-Draft.  Internet-Drafts are working
  16.      documents of the Internet Engineering Task Force (IETF), its
  17.      areas, and its working groups.  Note that other groups may also
  18.      distribute working documents as Internet-Drafts.
  19.  
  20.      Internet-Drafts are draft documents valid for a maximum of six
  21.      months and may be updated, replaced, or obsoleted by other
  22.      documents at any time.  It is inappropriate to use Internet-
  23.      Drafts as reference material or to cite them other than as
  24.      ``work in progress.''
  25.  
  26.      To learn the current status of any Internet-Draft, please check
  27.      the ``1id-abstracts.txt'' listing contained in the Internet-
  28.      Drafts Shadow Directories on ftp.is.co.za (Africa),
  29.      ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  30.      ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  31.  
  32.  
  33. Abstract
  34.  
  35.    Several label switching schemes have been proposed to fuse and
  36.    integrate Layer 2 and Layer 3.  ATM Label Switching Router (ATM-LSR)
  37.    is one of the major applications of label switching.  Some ATM-LSRs
  38.    will need to support ATM SVC services, which requires signaling to
  39.    establish VCs before employing them and to release VCs after
  40.    utilizing them.  This document proposes procedures to deal with ATM
  41.    SVCs between ATM-LSRs.
  42.  
  43.  
  44. 1. Introduction
  45.  
  46.    Several label switching schemes[ARIS][RFC2098][RFC1953][RFC2105] have
  47.    been proposed to fuse and integrate the cost-performance and QoS
  48.    assurance of Layer 2 devices and the flexibility and functionality of
  49.    Layer 3 protocols.
  50.  
  51.  
  52.  
  53. Demizu, et al.                                                  [Page 1]
  54.  
  55. Internet Draft      draft-demizu-mpls-atm-svc-00.txt        October 1997
  56.  
  57.  
  58.    These label switching schemes can be applied to various datalinks.
  59.    ATM Label Switching Router (ATM-LSR) is one of the major applications
  60.    of label switching.  Some ATM-LSRs will need to support ATM SVC,
  61.    which requires signaling to establish Virtual Connections (VCs)
  62.    before employing them and to release VCs after utilizing them.
  63.  
  64.    This document proposes procedures to deal with ATM SVCs between ATM-
  65.    LSRs.
  66.  
  67.    Although ATM address selection is important to set up ATM SVCs, it is
  68.    out of the scope of this document.  ATM-LSRs should have ATM address
  69.    selection mechanisms such as static configuration, ATM ARP, and NHRP.
  70.  
  71.  
  72. 2. ATM Forum Signaling
  73.  
  74.    The ATM Forum defines a signaling protocol to set up SVCs.  In this
  75.    document, it is called "ATM Forum Signaling".
  76.  
  77.    Callers can transfer out-of-band information to callees by the ATM
  78.    Forum Signaling.  BLLI is one of information that must be transferred
  79.    and is a user specific 7 bit field in the Layer 3 protocol field in
  80.    the BLLI IE (Broadband Low Layer Information, Information Element).
  81.    When a new VC is established by ATM Forum Signaling, the callee can
  82.    read the BLLI value and caller's ATM address of the VC.
  83.  
  84.    In the proposal of this document, the BLLI value is used as a
  85.    temporary identifier for a VC during a VCID notification procedure,
  86.    which follows the "Outband Notification by using a small sized field"
  87.    method described in [VCID].  So the BLLI value of a new VC should not
  88.    be assigned for other VCs during the procedure to avoid conflicts.
  89.    After the association of the VC having the BLLI value to a VCID has
  90.    been completed, the BLLI value of the new VC can be assigned to other
  91.    VCs.  VCID values can be assigned independently from BLLI values.
  92.  
  93.    A point-to-multipoint VC can also be established by using ADD_PARTY
  94.    of ATM Forum Signaling.  ADD_PARTY adds a new VC leaf to an existing
  95.    VC or an existing VC tree and makes a point-to-multipoint VC tree as
  96.    a result.  In this procedure, the BLLI value of ADD_PARTY should be
  97.    the same value as that was used to establish the first point-to-point
  98.    VC of the tree.  However, different VC trees can use the same BLLI
  99.    value without any conflicts between them if VC trees that use the
  100.    same BLLI value do not establish VCs nor add VCs simultaneously.  So
  101.    the BLLI value used for signaling should be determined by the root
  102.    node of multicast tree for consistency.
  103.  
  104.    The remaining part of this document describes the outlines of
  105.    procedures to notify a VCID value between a caller and a callee.
  106.  
  107.  
  108.  
  109. Demizu, et al.                                                  [Page 2]
  110.  
  111. Internet Draft      draft-demizu-mpls-atm-svc-00.txt        October 1997
  112.  
  113.  
  114.    Detailed procedures should be defined for each label distribution
  115.    protocol.
  116.  
  117.  
  118. 3. Support for Unicast Traffic
  119.  
  120.    This section proposes procedures to establish a VC and to notify its
  121.    VCID between neighboring LSRs for unicast traffic.  VC pool[VCPOOL]
  122.    is used for unicast.
  123.  
  124.    This document proposes following procedures, for when an upstream LSR
  125.    allocates a VCID for a new VC.
  126.  
  127.         0. In the case where a downstream LSR starts to prepare a VC in
  128.            the VC pool, the downstream LSR sends a VC establishment
  129.            request message to its upstream LSR.  Otherwise, skip step 0.
  130.  
  131.         1. An upstream LSR establishes a VC by ATM Forum Signaling
  132.            between the downstream LSR with a unique BLLI value at this
  133.            moment.
  134.            (If the association between the VC and a VCID should be
  135.             postponed until the VC starts to be used, suspend here.)
  136.         2. The upstream LSR notifies a pair of the BLLI value and a
  137.            VCID to the downstream LSR by using a message dedicated
  138.            for this purpose or together within a BIND message.
  139.         3. The downstream LSR associates the VC having the BLLI value
  140.            with the VCID, and sends an ACK message to the upstream
  141.            LSR.  If the VCID is used by some other VC between the
  142.            upstream, the old VC is discarded.
  143.         4. After the upstream LSR receives the ACK message,
  144.            it associates the VC with the VCID. The VC is ready to be
  145.            used at this step, and the BLLI value that was allocated to
  146.            the VC can be re-used for another VC.
  147.  
  148.    This document proposes following procedures for when a downstream LSR
  149.    allocates a VCID for a new VC.
  150.  
  151.         0. In the case where a downstream LSR starts to prepare a VC in
  152.            the VC pool, the downstream LSR sends a VC establishment
  153.            request message to its upstream LSR.  Otherwise, skip step 0.
  154.  
  155.         1. An upstream LSR establishes a VC by ATM Forum Signaling
  156.            between the downstream LSR with a unique BLLI value at this
  157.            moment.
  158.            (If the association between the VC and a VCID should be
  159.             postponed until the VC starts to be used, suspend here.)
  160.         2. The downstream LSR notifies a pair of the BLLI value and a
  161.            VCID to the upstream LSR by using a message dedicated for
  162.  
  163.  
  164.  
  165. Demizu, et al.                                                  [Page 3]
  166.  
  167. Internet Draft      draft-demizu-mpls-atm-svc-00.txt        October 1997
  168.  
  169.  
  170.            this purpose or together within a BIND message.
  171.         3. The upstream LSR associates the VC having the BLLI value
  172.            with the VCID, and sends an ACK message to the downstream
  173.            LSR. If the VCID is used by some other VC between the
  174.            downstream, the old VC is discarded.
  175.         4. After the downstream LSR receives the ACK message,
  176.            it associates the VC with the VCID. The VC is ready to be
  177.            used at this step, and the BLLI value that was allocated to
  178.            the VC can be re-used for other VC.
  179.  
  180.  
  181. 4. Support for multicast traffic
  182.  
  183.    This section proposes procedures to establish the first VC for a
  184.    multicast stream and to add a new VC leaf to an existing VC tree
  185.    including the notification of its VCID for a multicast stream by
  186.    using point-to-multipoint VCs.
  187.  
  188.    In this proposal, an upstream LSR determines both VCID and BLLI value
  189.    in the multicast case.  The reason the BLLI value is determined by an
  190.    upstream LSR is described in Section 2.  Since it is difficult to
  191.    recycle point-to-multipoint VCs, the VC pool is not used for
  192.    multicast.
  193.  
  194.    This document proposes the following procedure to establish the first
  195.    VC.
  196.  
  197.         1. An upstream LSR establishes a VC by ATM Forum Signaling
  198.            between the downstream LSR with a unique BLLI value at this
  199.            moment.
  200.         2. The upstream LSR notifies a pair of the BLLI value and a
  201.            VCID to the downstream LSR by using a message dedicated
  202.            for this purpose or together within a BIND message.
  203.         3. The downstream LSR associates the VC having the BLLI value
  204.            with the VCID, and sends an ACK message to the upstream
  205.            LSR.  If the VCID is used by some other VC between the
  206.            upstream, the old VC is discarded.
  207.         4. After the upstream LSR receives the ACK message, the VC is
  208.            ready to be used and the BLLI value can be used for another
  209.            VC.
  210.  
  211.    This document proposes the following procedures for the second VC or
  212.    later.
  213.  
  214.         1. The upstream LSR establishes a VC by ATM Forum Signaling
  215.            between its downstream LSR with the BLLI value that was
  216.            used during the first signaling procedure.  If another VC
  217.            is using the BLLI value at the same time, the upstream
  218.  
  219.  
  220.  
  221. Demizu, et al.                                                  [Page 4]
  222.  
  223. Internet Draft      draft-demizu-mpls-atm-svc-00.txt        October 1997
  224.  
  225.  
  226.            waits for the completion of the signaling procedure that is
  227.            using this BLLI value.
  228.         2. Goto step 2 of the procedure for the first VC.
  229.  
  230.  
  231. Security Considerations
  232.  
  233.    Security issues are not discussed in this document.
  234.  
  235.  
  236. Intellectual Property Considerations
  237.  
  238.    Toshiba Corporation may seek patent or other intellectual property
  239.    protection for some of the aspects of the technology discussed in
  240.    this document.  If any standards arising from this document are or
  241.    become protected by one or more patents assigned to Toshiba
  242.    Corporation, Toshiba intends to license them on reasonable and non-
  243.    discriminatory terms.
  244.  
  245.  
  246. Acknowledgments
  247.  
  248.    The authors would like to acknowledge valuable technical comments
  249.    from members of LAST-WG of WIDE Project.
  250.  
  251.  
  252. References
  253.  
  254. [ARIS]    A. Viswanathan, et al.,
  255.      "ARIS: Aggregate Route-Based IP Switching",
  256.      draft-viswanathan-aris-overview-00.txt, Mar 1997
  257. [RFC2098] Y. Katsube, et al.,
  258.      "Toshiba's Router Architecture Extensions for ATM : Overview",
  259.      RFC2098, Feb 1997
  260. [RFC1953] P. W. Edwards, et al.,
  261.      "Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0",
  262.      RFC1953, May 1996
  263. [RFC2105] Y. Rekhter, et al.,
  264.      "Cisco Systems' Tag Switching Architecture Overview",
  265.      RFC2105, Feb 1997
  266. [ATM_SVC] H. Esaki, et al.,
  267.        "IP Address Resolution and ATM Signaling for MPLS over ATM SVC services"
  268.      draft-katsube-mpls-over-svc-00.txt, Jun 1997
  269. [TAG_ATM] B. Davie, et al.,
  270.      "Use of Tag Switching With ATM"
  271.      draft-davie-tag-switching-atm-01.txt, Jan 1997
  272. [VCID]    N. Demizu, et al.,
  273.      "VCID: Virtual Connection Identifier",
  274.  
  275.  
  276.  
  277. Demizu, et al.                                                  [Page 5]
  278.  
  279. Internet Draft      draft-demizu-mpls-atm-svc-00.txt        October 1997
  280.  
  281.  
  282.      draft-demizu-mpls-vcid-01.txt, Oct 1997
  283. [VCPOOL] N. Demizu, et al.,
  284.      "VC pool",
  285.      draft-demizu-mpls-vcpool-00.txt, Oct 1997
  286.  
  287.  
  288. Authors Information
  289.  
  290.    Noritoshi Demizu
  291.    Sony Computer Science Laboratory, Inc.
  292.    Takanawa Muse Bldg.
  293.    3-14-13, Higashigotanda,
  294.    Shinagawa-ku, Tokyo, 141 Japan
  295.    Phone: +81-3-5448-4380
  296.    E-mail: demizu@csl.sony.co.jp
  297.    E-mail: nori-d@is.aist-nara.ac.jp
  298.  
  299.    Ken-ichi Nagami
  300.    R&D Center, Toshiba Corporation,
  301.    1 Komukai-Toshiba-cho, Saiwai-ku,
  302.    Kawasaki, 210, Japan
  303.    Email: nagami@isl.rdc.toshiba.co.jp
  304.  
  305.    Paul Doolan
  306.    cisco Systems, Inc.
  307.    250 Apollo Drive.
  308.    Chelmsford, MA 01824, USA
  309.    Phone: +1-508-244-8917
  310.    email: pdoolan@cisco.com
  311.  
  312.    Hiroshi Esaki
  313.    Computer and Network Division,
  314.    Toshiba Corporation,
  315.    1-1-1 Shibaura,
  316.    Minato-ku, 105-01, Japan
  317.    Email: hiroshi@isl.rdc.toshiba.co.jp
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Demizu, et al.                                                  [Page 6]
  334.  
  335.