RFC 4454 - Asynchronous Transfer Mode (ATM) over Layer 2 Tun

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroup S.Singh RequestforComments:4454M.Townsley Category:StandardsTrack C.Pignataro CiscoSystems May2006 AsynchronousTransferMode(ATM)over Layer2TunnelingProtocolVersion3(L2TPv3) StatusofThisMemo ThisdocumentspecifiesanInternetstandards
  Network Working Group                                               S. Singh
Request for Comments: 4454                                   M. Townsley
Category: Standards Track                                       C. Pignataro
                                                                             Cisco Systems
                                                                                   May 2006

                 Asynchronous Transfer Mode (ATM) over
             Layer 2 Tunneling Protocol Version 3 (L2TPv3)

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

Abstract

   The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an
   extensible tunneling protocol to transport layer 2 services over IP
   networks.  This document describes the specifics of how to use the
   L2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires
   and provides guidelines for transporting various ATM services over an
   IP network.

Table of Contents

   1. Introduction ....................................................2
      1.1. Abbreviations ..............................................3
      1.2. Specification of Requirements ..............................3
   2. Control Connection Establishment ................................3
   3. Session Establishment and ATM Circuit Status Notification .......4
      3.1. L2TPv3 Session Establishment ...............................4
      3.2. L2TPv3 Session Teardown ....................................6
      3.3. L2TPv3 Session Maintenance .................................6
   4. Encapsulation ...................................................6
      4.1. ATM-Specific Sublayer ......................................7
      4.2. Sequencing .................................................9
   5. ATM Transport ...................................................9
      5.1. ATM AAL5-SDU Mode .........................................10
      5.2. ATM Cell Mode .............................................10

           5.2.1. ATM VCC Cell Relay Service .........................11
           5.2.2. ATM VPC Cell Relay Service .........................12
           5.2.3. ATM Port Cell Relay Service ........................12
      5.3. OAM Cell Support ..........................................12
           5.3.1. VCC Switching ......................................12
           5.3.2. VPC Switching ......................................13
   6. ATM Maximum Concatenated Cells AVP .............................13
   7. OAM Emulation Required AVP .....................................14
   8. ATM Defects Mapping and Status Notification ....................14
      8.1. ATM Alarm Status AVP ......................................14
   9. Applicability Statement ........................................15
      9.1. ATM AAL5-SDU Mode .........................................16
      9.2. ATM Cell Relay Mode .......................................18
   10. Congestion Control ............................................20
   11. Security Considerations .......................................21
   12. IANA Considerations ...........................................21
      12.1. L2-Specific Sublayer Type ................................21
      12.2. Control Message Attribute Value Pairs (AVPs) .............21
      12.3. Result Code AVP Values ...................................22
      12.4. ATM Alarm Status AVP Values ..............................22
      12.5. ATM-Specific Sublayer Bits ...............................23
   13. Acknowledgements ..............................................23
   14. References ....................................................23
      14.1. Normative References .....................................23
      14.2. Informative References ...................................24

1.  Introduction

   This document describes the specifics of how to use the Layer 2
   Tunneling Protocol (L2TP) for Asynchronous Transfer Mode (ATM)
   Pseudowires, including encapsulation, carrying various ATM services,
   such as AAL5 SDU, ATM VCC/VPC/Port cell relay over L2TP, and mapping
   ATM defects to L2TP Set-Link-Info (SLI) messages to notify the peer
   L2TP Control Connection Endpoint (LCCE).

   Any ATM-specific AVPs or other L2TP constructs for ATM Pseudowire
   (ATMPW) support are defined here as well.  Support for ATM Switched
   Virtual Path/Connection (SVP/SVC) and Soft Permanent Virtual
   Path/Connection (SPVP/SPVC) are outside the scope of this document.

   The reader is expected to be very familiar with the terminology and
   protocol constructs defined in [RFC3931].

1.1.  Abbreviations

   AIS     Alarm Indication Signal
   ATMPW   ATM Pseudowire
   AVP     Attribute Value Pair
   CC      Continuity Check OAM Cell
   CE      Customer Edge
   HEC     Header Error Checksum
   LAC     L2TP Access Concentrator (see [RFC3931])
   LCCE    L2TP Control Connection Endpoint (see [RFC3931])
   MSB     Most Significant Byte
   OAM     Operation, Administration, and Maintenance
   PE      Provider Edge
   PSN     Packet Switched Network
   PWE3    Pseudowire Emulation Edge to Edge
   RDI     Remote Defect Indicator
   SAR     Segmentation and Reassembly
   SDU     Service Data Unit
   SLI     Set-Link-Info, an L2TP control message
   SVC     Switched Virtual Connection
   SVP     Switched Virtual Path
   SPVC    Soft Permanent Virtual Connection
   SPVP    Soft Permanent Virtual Path
   VC      Virtual Circuit
   VCC     Virtual Channel Connection
   VCI     Virtual Channel Identifier
   VPC     Virtual Path Connection
   VPI     Virtual Path Identifier

1.2.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

2.  Control Connection Establishment

   To emulate ATM Pseudowires using L2TP, an L2TP Control Connection as
   described in Section 3.3 of [RFC3931] MUST be established.

   The Start-Control-Connection-Request (SCCRQ) and corresponding
   Start-Control-Connection-Reply (SCCRP) MUST include the supported ATM
   Pseudowire types (see Section 3.1), in the Pseudowire Capabilities
   List as defined in Section 5.4.3 of [RFC3931].  This identifies the
   Control Connection as able to establish L2TP sessions in support of
   the ATM Pseudowires.

   An LCCE MUST be able to uniquely identify itself in the SCCRQ and
   SCCRP messages via a globally unique value.  By default, this is
   advertised via the structured Router ID AVP [RFC3931], though the
   unstructured Hostname AVP [RFC3931] MAY be used to identify LCCEs as
   well.

3.  Session Establishment and ATM Circuit Status Notification

   This section describes how L2TP ATMPWs or sessions are established
   between two LCCEs.  This includes what will happen when an ATM
   circuit (e.g., AAL5 PVC) is created, deleted, or changes state when
   circuit state is in alarm.

3.1.  L2TPv3 Session Establishment

   ATM circuit (e.g., an AAL5 PVC) creation triggers establishment of an
   L2TP session using three-way handshake described in Section 3.4.1 of
   [RFC3931].  An LCCE MAY initiate the session immediately upon ATM
   circuit creation, or wait until the circuit state transitions to
   ACTIVE before attempting to establish a session for the ATM circuit.
   It MAY be preferred to wait until circuit status transitions to
   ACTIVE in order to delay the allocation of resources until absolutely
   necessary.

   The Circuit Status AVP (see Section 8) MUST be present in the
   Incoming-Call-Request (ICRQ) and Incoming-Call-Reply (ICRP) messages,
   and MAY be present in the SLI message for ATMPWs.

   The following figure shows how L2TP messages are exchanged to set up
   an ATMPW after the ATM circuit (e.g., an AAL5 PVC) becomes ACTIVE.

          LCCE (LAC) A                                  LCCE (LAC) B
      ------------------                            --------------------

       ATM Ckt Provisioned
                                                    ATM Ckt Provisioned
       ATM Ckt ACTIVE
                       ICRQ (status = 0x03) ---->
                                                    ATM Ckt ACTIVE
                       <----- ICRP (status = 0x03)
       L2TP session established
       OK to send data into PW

                       ICCN ----->
                                               L2TP session established
                                               OK to send data into PW

   The following signaling elements are required for the ATMPW
   establishment.

   a. Pseudowire Type: One of the supported ATM-related PW types should
      be present in the Pseudowire Type AVP of [RFC3931].

      0x0002  ATM AAL5 SDU VCC transport
      0x0003  ATM Cell transport Port Mode
      0x0009  ATM Cell transport VCC Mode
      0x000A  ATM Cell transport VPC Mode

   The above cell relay modes can also signal the ATM Maximum
   Concatenated Cells AVP as described in Section 6.

   b. Remote End ID: Each PW is associated with a Remote End ID akin to
      the VC-ID in [PWE3ATM].  Two LCCEs of a PW would have the same
      Remote End ID, and its format is described in Section 5.4.4 of
      [RFC3931].

      This Remote End ID AVP MUST be present in the ICRQ in order for
      the remote LCCE to associate the session to the ATM circuit.  The
      Remote End Identifier AVP defined in [RFC3931] is of opaque form,
      though ATMPW implementations MAY simply use a 4-octet value
      that is known to both LCCEs (either by direct configuration or
      some other means).  The exact method of how this value is
      configured, retrieved, discovered, or otherwise determined at
      each LCCE is outside the scope of this document.

   As with the ICRQ, the ICRP is sent only after the ATM circuit
   transitions to ACTIVE.  If LCCE B had not been provisioned yet for
   the ATM circuit identified in the ICRQ, a Call-Disconnect-Notify
   (CDN) would have been immediately returned indicating that the
   circuit either was not provisioned or was not available at this LCCE.
   LCCE A SHOULD then exhibit a periodic retry mechanism.  If so, the
   period and maximum number of retries MUST be configurable.

   An implementation MAY send an ICRQ or ICRP before a PVC is ACTIVE, as
   long as the Circuit Status AVP reflects that the ATM circuit is
   INACTIVE and an SLI is sent when the ATM circuit becomes ACTIVE (see
   Section 8).

   The ICCN is the final stage in the session establishment.  It
   confirms the receipt of the ICRP with acceptable parameters to allow
   bidirectional traffic.

3.2.  L2TPv3 Session Teardown

   When an ATM circuit is unprovisioned (deleted) at either LCCE, the
   associated L2TP session MUST be torn down via the CDN message defined
   in Section 3.4.3 of [RFC3931].

3.3.  L2TPv3 Session Maintenance

   All sessions established by a given Control Connection utilize the
   L2TP Hello facility defined in Section 4.4 of [RFC3931] for session
   keepalive.  This gives all sessions basic dead peer and path
   detection between LCCEs.

   If the control channel utilizing the Hello message is not in-band
   with data traffic over the PSN, then other method MAY be used to
   detect the session failure, and it is left for further study.

   ATMPWs over L2TP use the Set-Link-Info (SLI) control message as
   defined in [RFC3931] to signal ATM circuit status between LCCEs after
   initial session establishment.  This includes ACTIVE or INACTIVE
   notifications of the ATM circuit, or any other parameters that may
   need to be shared between the LCCEs in order to provide proper PW
   emulation.

   The SLI message MUST be sent whenever there is a status change that
   may be reported by any values identified in the Circuit Status AVP.
   The only exceptions to this are the initial ICRQ, ICRP, and CDN
   messages, which establish and tear down the L2TP session itself when
   the ATM circuit is created or deleted.  The SLI message may be sent
   from either LCCE at any time after the first ICRQ is sent (and
   perhaps before an ICRP is received, requiring the peer to perform a
   reverse Session ID lookup).

   The other application of the SLI message is to map the ATM OAM or
   physical layer alarms into Circuit Status AVP as described in Section
   8.

4.  Encapsulation

   This section describes the general encapsulation format for ATM
   services over L2TP.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     PSN Transport Header                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Session Header                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ATM-Specific Sublayer                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      ATM Service Payload                      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 1: General Format for ATM Encapsulation over L2TPv3 over IP

   The PSN Transport header is specific to IP and its underlying
   transport header.  This header is used to transport the encapsulated
   ATM payload through the IP network.

   The Session Header is a non-zero 32-bit Session ID with an optional
   Cookie up to 64-bits.  This Session ID is exchanged during session
   setup.

   The ATM-Specific Sublayer is REQUIRED for AAL5 SDU Mode and OPTIONAL
   for ATM Cell Mode.  Please refer to Section 4.1 for more details.

4.1.  ATM-Specific Sublayer

   This section defines a new ATM-Specific Sublayer, an alternative to
   the Default L2-Specific Sublayer as mentioned in Section 4.6 of
   [RFC3931].  Four new flag bits (T, G, C, and U) are defined that
   concur with Section 8.2 of [PWE3ATM].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|S|B|E|T|G|C|U|          Sequence Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: ATM-Specific Sublayer Format

   The meaning of the fields of the ATM-Specific Sublayer is as follows:

      * S bit

      Definition of this bit is as per Section 4.6 of [RFC3931].

      * B and E bits

      Definitions of these bits are as per Section 5.5 of [L2TPFRAG].

      If these bits are not used as per [L2TPFRAG], they MUST be set to
      0 upon transmission and ignored upon reception.

      * T (Transport type) bit

      Bit (T) of the ATM-Specific Sublayer indicates whether the packet
      contains an ATM admin cell or an AAL5 payload.  If T = 1, the
      packet contains an ATM admin cell, encapsulated according to the
      VCC cell relay encapsulation of Section 5.2.

      If not set, the PDU contains an AAL5 payload.  The ability to
      transport an ATM cell in the AAL5 SDU Mode is intended to provide
      a means of enabling administrative functionality over the AAL5 VCC
      (though it does not endeavor to preserve user-cell and admin-cell
      arrival/transport ordering, as described in Section 9.1).

      * G (EFCI) Bit

      The ingress LCCE device SHOULD set this bit to 1 if the Explicit
      Forward Congestion Indication (EFCI) bit of the final cell of the
      incoming AAL5 payload is set to 1, or if the EFCI bit of the
      single ATM cell to be transported in the packet is set to 1.
      Otherwise, this bit SHOULD be set to 0.  The egress LCCE device
      SHOULD set the EFCI bit of all the outgoing cells that transport
      the AAL5 payload to the value contained in this field.

      * C (CLP) Bit

      The ingress LCCE device SHOULD set this bit to 1 if the Cell Loss
      Priority (CLP) bit of any of the incoming ATM cells of the AAL5
      payload is set to 1, or if the CLP bit of the single ATM cell that
      is to be transported in the packet is set to 1.  Otherwise this
      bit SHOULD be set to 0.  The egress LCCE device SHOULD set the CLP
      bit of all outgoing cells that transport the AAL5 CPCS-PDU to the
      value contained in this field.

      * U (Command/Response) Bit

      When FRF.8.1 Frame Relay / ATM PVC Service Interworking (see
      [FRF8.1]) traffic is being transported, the CPCS-UU Least
      Significant Bit (LSB) of the AAL5 CPCS-PDU may contain the Frame
      Relay C/R bit.  The ingress LCCE device SHOULD copy this bit to
      the U bit of the ATM-Specific Sublayer.  The egress LCCE device
      SHOULD copy the U bit to the CPCS-UU Least Significant Bit (LSB)
      of the AAL5 payload.

      The Sequence Number field is used in sequencing, as described in
      Section 4.2.

   In case of a reassembly timeout, the encapsulating LCCE should
   discard all component cells of the AAL5 frame.

   An additional enumeration is added to the L2-Specific Sublayer AVP to
   identify the ATM-Specific Sublayer:

         0 - There is no L2-Specific Sublayer present.
         1 - The Default L2-Specific Sublayer (defined in Section 4.6
             of [RFC3931]) is used.
         2 - The ATM-Specific Sublayer is used.

   The first two values are already defined in the L2TPv3 base
   specification [RFC3931].

4.2.  Sequencing

   Data Packet Sequencing MAY be enabled for ATMPWs.  The sequencing
   mechanisms described in [RFC3931] MUST be used to signal sequencing
   support.  ATMPWs over L2TPv3 MUST request the presence of the ATM-
   Specific Sublayer when sequencing is enabled, and MAY request its
   presence at all times.

5.  ATM Transport

   There are two encapsulations supported for ATM transport as described
   below.

   The ATM-Specific Sublayer is prepended to the AAL5-SDU.  The other
   cell mode encapsulation consists of the OPTIONAL ATM-Specific
   Sublayer, followed by a 4-byte ATM cell header and a 48-byte ATM
   cell-payload.

5.1.  ATM AAL5-SDU Mode

   In this mode, each AAL5 VC is mapped to an L2TP session.  The Ingress
   LCCE reassembles the AAL5 CPCS-SDU without the AAL5 trailer and any
   padding bytes.  Incoming EFCI, CLP, and C/R (if present) are carried
   in an ATM-Specific Sublayer across ATMPWs to the egress LCCE.  The
   processing of these bits on ingress and egress LCCEs is defined in
   Section 4.1.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|S|x|x|T|G|C|U|             Sequence Number                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                         AAL5 CPCS-SDU                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: ATM AAL5-SDU Mode Encapsulation

   If the ingress LCCE determines that an encapsulated AAL5 SDU exceeds
   the MTU size of the L2TPv3 session, then AAL5 SDU may be fragmented
   as per [L2TPFRAG] or underneath the transport layer (IP, etc.).  F5
   OAM cells that arrive during the reassembly of an AAL5 SDU are sent
   immediately on the PW followed by the AAL5 SDU payload.  In this
   case, OAM cells’ relative order with respect to user data cells is
   not maintained.

   Performance Monitoring OAM, as specified in ITU-T 610 [I610-1],
   [I610-2], [I610-3] and security OAM cells as specified in [ATMSEC],
   should not be used in combination with AAL5 SDU Mode.  These cells
   MAY be dropped at the ingress LCCE because cell sequence integrity is
   not maintained.

   The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931],
   Attribute Type 68, MUST be present in the ICRQ messages and MUST
   include the ATM AAL5 SDU VCC transport PW Type of 0x0002.

5.2.  ATM Cell Mode

   In this mode, ATM cells skip the reassembly process at the ingress
   LCCE.  These cells are transported over an L2TP session, either as a
   single cell or as concatenated cells, into a single packet.  Each ATM
   cell consists of a 4-byte ATM cell header and a 48-byte ATM cell-
   payload; the HEC is not included.

   In ATM Cell Mode encapsulation, the ATM-Specific Sublayer is
   OPTIONAL.  It can be included, if sequencing support is required.  It
   is left to the implementation to choose to signal the Default L2-
   Specific Sublayer or the ATM-Specific Sublayer.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|S|x|x|x|x|x|x|          Sequence Number (Optional)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        VPI            |           VCI                 |PTI  |C|
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容