rfc3038.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/3 页

Network Working Group                                          K. Nagami
Request for Comments: 3038                                    Y. Katsube
Category: Standards Track                                  Toshiba Corp.
                                                               N. Demizu
                                                        WaterSprings.ORG
                                                                H. Esaki
                                                          Univ. of Tokyo
                                                               P. Doolan
                                                       Ennovate Networks
                                                            January 2001

                VCID Notification over ATM link for LDP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is
   one of the major applications of label switching.  Because the ATM
   layer labels (VPI and VCI) associated with a VC rewritten with new
   value at every ATM switch nodes, it is not possible to use them to
   identify a VC in label mapping messages.  The concept of Virtual
   Connection Identifier (VCID) is introduced to solve this problem.
   VCID has the same value at both ends of a VC.  This document
   specifies the procedures for the communication of VCID values between
   neighboring ATM-LSRs that must occur in order to ensure this
   property.

1. Introduction

   Several label switching schemes have been proposed to integrate Layer
   2 and Layer 3.  The ATM Label Switching Router (ATM-LSR) is one of
   the major applications of label switching.

   In the case of ATM VCs, the VPI and VCI labels are, in the general
   case, rewritten with new values at every switch node through which
   the VC passes and cannot be used to provide end to end identification
   of a VC.



Nagami, et al.              Standards Track                     [Page 1]

RFC 3038               VCID Notification for LDP            January 2001


   In the context of MPLS 'stream', which are classes of packets that
   have some common characteristic that may be deduced by examination of
   the layer 3 header in the packets, are bound to layer 2 'labels'. We
   speak of stream being 'bound' to labels.  These bindings are conveyed
   between peer LSRs by means of a Label Distribution Protocol [LDP].

   In order to apply MPLS to ATM links, we need some way to identify ATM
   VCs in LDP mapping messages.  An identifier called a Virtual
   Connection ID (VCID) is introduced.  VCID has the same value at both
   ends of a VC.  This document specifies the procedures for the
   communication of VCID values between neighboring ATM-LSRs that must
   occur in order to ensure this property.

2. Overview of VCID Notification Procedures

2.1 VCID Notification procedures

   The ATM has several types of VCs (transparent point-to-point
   link/VP/PVC/SVC).  A transparent point-to-point link is defined as
   one that has the same VPI/VCI label at both ends of a VC.  For
   example, two nodes are directly connected (i.e., without intervening
   ATM switches) or are connected through a VP with the same VPI value
   at both ends of the VP.

   There are two broad categories of VCID notification procedures;
   inband and outband.  The categorization refers to the connection over
   which the messages of the VCID notification procedure are forwarded.
   In the case of the inband procedures, those messages are forwarded
   over the VC to which they refer.  In contrast the out of band
   procedures transmit the messages over some other connection (than the
   VC to which they refer).

   We list below the various types of link and briefly mention the VCID
   notification procedures employed and the rational for that choice.
   The procedures themselves are discussed in detail in later sections.

   Transparent point-to-point link : no VCID notification
       VCID notification procedure is not necessary because the label
       (i.e., VPI/VCI) is the same at each end of the VC.

   VP : inband notification or VPID notification or no notification
    - Inband notification
      VCID notification is needed because the VPI at each end of the VC
      may not be the same.  Inband VCID notification is used in this
      case.






Nagami, et al.              Standards Track                     [Page 2]

RFC 3038               VCID Notification for LDP            January 2001


    - VPID notification
      VCID notification is needed because the VPI at each end of the VC
      may not be the same.  VPID notification is used in this case.

    - No notification
      If a node has only one VP to a neighboring node, VCID notification
      procedure is not mandatory.  The VCI can be used as the VCID.
      This is because the VCI value is the same at each end of the VP.

   PVC : inband notification
      Inband VCID notification is used in this case because the labels
      at each end of the VC may not be the same.

   SVC : there are three possibilities
    - Outband notification
      If a signaling message has a field which is large enough to carry
      a VCID value (e.g., GIT [GIT]), then the VCID is carried directly
      in it.

    - Outband notification using a small-sized field
      If a signaling message has a field which is not large enough to
      carry a VCID value, this procedure is used.

    - Inband notification
      If a signaling message can not carry user information, this
      procedure is used.

      When an LSP is a point-to-multipoint VC and an ATM switch in an
      LSR is not capable of VC merge, it may cause problems in
      performance and quality of service.  When the LSR wants to add a
      new leaf to the LSP, it needs to split the active LSP temporarily
      to send an inband notification message.

2.2 VC direction

   A VC has a directionality.  The VCID procedure for a VC is always
   triggered from the upstream node of the VC, i.e., the upstream node
   notifies the downstream node of the VCID.

   If bidirectional use of a label switched VC is allowed, the label
   switched VC is said to be bidirectional.  In this case, two VCID
   procedures are taken, one for each direction.

   If bidirectional use of a label switched VC is not allowed, the label
   switched VC is said to be unidirectional.  In this case, only one
   VCID procedure is taken for the allowed direction.

   VC directionality is communicated through LDP.



Nagami, et al.              Standards Track                     [Page 3]

RFC 3038               VCID Notification for LDP            January 2001


3. VCID Notification Procedures

3.1 Inband Notification Procedures

3.1.1 Inband Notification for Point-to-point VC

   VCID notification is performed by transmitting a control message
   through the VC newly established (by signalling or management) for
   use as an label switched path (LSP).  The procedure for VCID
   notification between two nodes A and B is detailed below.

   0. The node A establishes a VC to the destination node B (by
      signalling or management).

   1. The node A selects a VCID value.

   2. The node A sends a VCID PROPOSE message which contains the VCID
      value and a message ID through the newly established VC to the
      node B.

   3. The node A establishes an association between the outgoing label
      (VPI/VCI) for the VC and the VCID value.

   4. The node B receives the message from the VC and establishes an
      association between the VCID in the message and the incoming
      label(VPI/VCI) for the VC.  Until the node B receives the LDP
      Request message, the node B discards any packet received over the
      VC other than the VCID PROPOSE message.

   5. The node B sends an ACK message to the node A.  This message
      contains the same VCID and message ID as specified in the received
      message.  This message is sent through the VC for LDP.

   6. When node A receives the ACK message, it checks whether the VCID
      and the message ID in the message are the same as the registered
      ones.  If they are the same, node A regards that node B has
      established the association between the VC and VCID.  Otherwise,
      the message is ignored.  If the node A does not receive the ACK
      message with the expected message ID and VCID during a given
      period, the node A resends the VCID PROPOSE message to the node B.

   7. After receiving the proposer ACK message, the node A sends an LDP
      REQUEST message to the node B.  It contains the message ID used
      for VCID PROPOSE.  When the node B receives the LDP REQUEST
      message, it regards that the node A has received the ACK
      correctly.  The message exchange using VCID PROPOSE, VCID ACK, and
      LDP REQUEST messages constitutes a 3-way handshake.  The 3-way
      handshake mechanism is required since the transmission of VCID



Nagami, et al.              Standards Track                     [Page 4]

RFC 3038               VCID Notification for LDP            January 2001


      PROPOSE message is unreliable.  Once the 3-way handshake
      completes, the node B ignores all VCID PROPOSE messages received
      over the VC.  The node B sends an LDP Mapping message, which
      contains the VCID value in the label TLV.

       Node A           Node B
         |                |
         |--------------->|     VCID PROPOSE
         |                |
         |<---------------|     VCID ACK
         |                |
         |--------------->|     LDP Label Request
         |                |
         |<---------------|     LDP Label Mapping

3.1.2 Inband notification for point-to-multipoint VC

   Current LDP specification does not support multicast.  But the VCID
   notification procedure is defined for future use.  VCID notification
   is performed by sending a control message through the VC to be used
   as an LSP.  The upstream node assigns the VCID value.  The procedure
   by which it notifies the downstream node of that value is given
   below.  The procedure is used when a new VC is created or a new leaf
   is added to the VC.

   First, the procedure for establishing the first VC is described.

   1. The upstream node assigns a VCID value for the VC.  When the VCID
      value is already assigned to a VC, it is used for VCID.

   2. The upstream node sends a message which contains the VCID value
      and a message ID through the VC used for an LSP.  This message is
      transferred to all leaf nodes.

   3. The upstream node establishes an association between the outgoing
      label for the VC and the VCID value.

   4. When the downstream nodes receiving the message already received
      the LDP REQUEST message for the VC, the received message is
      discarded.  Otherwise, the downstream nodes establish an
      association between the VCID in the message and the VC from which
      the message is received.

   5. The downstream nodes send an ACK message to the upstream node.

   6. After the upstream node receives the ACK messages, the upstream
      node and the downstream nodes share the VCID.  The upstream node
      sends the LDP REQUEST message in order to make a 3-way handshake.



Nagami, et al.              Standards Track                     [Page 5]

RFC 3038               VCID Notification for LDP            January 2001


       Upstream        Downstream 1   Downstream 2
         |                |               |
         |-----------+--->|               |   VCID PROPOSE
         |           +------------------->|
         |                |               |
         |<---------------|               |
         |  VCID ACK      |               |
         |<-------------------------------|   VCID ACK

   Second, the procedure for adding a leaf to the existing point-to-
   multipoint VC is described.

   0. The upstream node adds the downstream node, using the ATM
      signaling.

   1. The VCID value which already assigned to the VC is used.

   2. The upstream node sends a message which contains the VCID value
      and a message ID through the VC used for an LSP.  This message is
      transferred to all leaf nodes.

   3. When the downstream nodes receiving the message already received
      the LDP REQUEST message for the VC, the received message is
      discarded.  Otherwise, the downstream nodes establish an
      association between the VCID in the message and the VC from which
      the message is received.

   4. After the upstream node receives the ACK messages, the upstream
      node and the downstream nodes share the VCID.  The upstream node
      sends the LDP REQUEST message in order to make a 3-way handshake.

3.2 Outband Notification using a small-sized field

   This method can be applied when a VC is established using an ATM
   signaling message and the message has a field which is not large
   enough to carry a VCID value.

   SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit mandatory
   field for the user.  This is a user specific field in the Layer 3
   protocol field in the BLLI IE (Broadband Low Layer Information
   Information Element).

   The BLLI value is used as a temporary identifier for a VC during a
   VCID notification procedure.  This mechanism is defined as "Outband
   Notification using a small-sized field".  The BLLI value of a new VC
   must not be assigned to other VCs during the procedure to avoid
   identifier conflict.  When the association among the BLLI value, a




Nagami, et al.              Standards Track                     [Page 6]

RFC 3038               VCID Notification for LDP            January 2001


   VCID value, and the corresponding VC is established, the BLLI value
   can be reused for a new VC.  VCID values can be assigned
   independently from BLLI values.

       Node A           Node B
         |                |
         |--------------->|     ATM Signaling with BLLI
         |<---------------|
         |                |
         |--------------->|     VCID PROPOSE with BLLI
         |                |
         |<---------------|     VCID ACK
         |                |
         |--------------->|     LDP Label Request