[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 6073

Network Working Group                                       Luca Martini
Internet Draft                                                Chris Metz
Expiration Date: September 2006                         Thomas D. Nadeau
                                                      Cisco Systems Inc.

Vasile Radoaca                                              Mike Duckett
Consultant                                                     Bellsouth

Matthew Bocci                                               Florin Balus
Alcatel                                                  Nortel Networks




                                                              March 2006


                         Segmented Pseudo Wire


                  draft-ietf-pwe3-segmented-pw-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.


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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.







Martini, et al.                                                 [Page 1]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


Abstract

   This document describes how to connect pseudo wires (PW) between two
   distinct PW control planes or PSN domains. The PW control planes may
   belong to independent autonomous systems, or the PSN technology is
   heterogeneous, or a PW might need to be aggregated at a specific PSN
   point. The PW packet data units are simply switched from one PW to
   another without changing the PW payload.











































Martini, et al.                                                 [Page 2]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006




Table of Contents

    1        Specification of Requirements  ........................   4
    2        Terminology  ..........................................   4
    3        Introduction  .........................................   5
    4        General Description  ..................................   6
    5        PW Switching with Attachment Circuits  ................   9
    5.1      Aplicability  .........................................   9
    6        PW-MPLS to PW-MPLS Control Plane Switching  ...........  10
    6.1      MPLS PW Control Plane Switching  ......................  11
    6.1.1    Static Control plane switching  .......................  11
    6.1.2    Two LDP control planes using the same FEC type  .......  11
    6.1.3    LDP using FEC 128 to LDP using the generalized FEC 129  ...12
    6.1.4    LDP PW switching point TLV  ...........................  12
    6.1.5    PW Switching Point Sub-TLVs  ..........................  13
    6.1.6    Adaptation of Interface Parameters  ...................  14
    6.1.7    Group ID  .............................................  15
    6.1.8    PW Loop Detection  ....................................  15
    7        PW-MPLS to PW-L2TPv3 Control Plane Switching  .........  15
    7.1      Static MPLS and L2TPv3 PWs  ...........................  16
    7.2      Static MPLS PW and Dynamic L2TPv3 PW  .................  16
    7.3      Static L2TPv3 PW and Dynamic LDP/MPLS PW  .............  16
    7.4      Dynamic LDP/MPLS and L2TPv3 PWs  ......................  16
    7.4.1    Session Establishment  ................................  17
    7.4.2    Adaptation of PW Status message  ......................  17
    7.4.3    Session Teardown  .....................................  18
    7.5      Adaptation of LDP/L2TPv3 AVPs and Interface Parameters  ...18
    7.6      Switching Point TLV in L2TPv3  ........................  19
    7.7      L2TPv3 and MPLS PW Data Plane  ........................  19
    7.7.1    PWE3 Payload Convergence and Sequencing  ..............  20
    7.7.2    Mapping  ..............................................  20
    8        Operation And Management  .............................  21
    8.1      Extensions to VCCV to Support Switched PWs  ...........  21
    8.2      PW-MPLS to PW-MPLS OAM Data Plane Indication  .........  21
    8.3      Signal OAM Capabilities for Switched Pseudo Wires  ....  22
    8.3.1    OAM Capability for MH PWs Demultiplexed using MPLS  ...  22
    8.3.2    OAM Capability for MH PWs Demultiplexed using L2TPv3  .  23
    8.4      Tracing Switched PW Switch Points Using MH-VCCV  ......  23
    8.5      Mapping Switched Pseudo Wire Status  ..................  23
    8.6      Pseudowire Status Negotiation Procedures  .............  25
    8.7      Status Dampening  .....................................  25
    9        Peering Between Autonomous Systems  ...................  25
   10        Security Considerations  ..............................  25
   10.1      Data Plane Security  ..................................  25
   10.2      Control Protocol Security  ............................  26
   11        IANA Considerations  ..................................  27



Martini, et al.                                                 [Page 3]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


   11.1      Channel  ..............................................  27
   11.2      L2TPv3 AVP  ...........................................  27
   11.3      LDP TLV TYPE  .........................................  27
   11.4      LDP Status Codes  .....................................  27
   11.5      L2TPv3 Result Codes  ..................................  28
   11.6      New IANA Registries  ..................................  28
   12        Intellectual Property Statement  ......................  28
   13        Full Copyright Statement  .............................  29
   14        Acknowledgments  ......................................  29
   15        Normative References  .................................  29
   16        Informative References  ...............................  30
   17        Author Information  ...................................  31






1. Specification of Requirements

   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 RFC 2119


2. Terminology

     - PW Terminating Provider Edge (T-PE). A PE where the customer-
       facing attachment circuits (ACs) are bound to a PW forwarder. A
       Terminating PE is present in the first and last segments of a
       MS-PW. This incorporates the functionality of a PE as defined in
       [RFC3985].

     - Single-Segment Pseudo Wire (SS-PW). A PW setup directly between
       two T-PE devices. Each PW in one direction of a SS-PW traverses
       one PSN tunnel that connects the two T-PEs.

     - Multi-Segment Pseudo Wire (MS-PW).  A static or dynamically
       configured set of two or more contiguous PW segments that behave
       and function as a single point-to-point PW. Each end of a MS-PW
       by definition MUST terminate on a T-PE.

     - PW Segment. A part of a single-segment or multi-segment PW, which
       is set up between two PE devices, T-PEs and/or S-PEs.







Martini, et al.                                                 [Page 4]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


     - PW Switching Provider Edge (S-PE).  A PE capable of switching the
       control and data planes of the preceding and succeeding PW
       segments in a MS-PW. The S-PE terminates the PSN tunnels of the
       preceding and succeeding segments of the MS-PW.It is therefore a

     - PW switching point for a MS-PW. A PW Switching Point is never the
       S-PE and the T-PE for the same MS-PW. A PW switching point runs
       necessary protocols to setup and manage PW segments with other PW
       switching points and terminating PEs.


3. Introduction

   PWE3 defines the signaling and encapsulation techniques for
   establishing SS-PWs between a pair of ultimate PEs and in the vast
   majority of cases this will be sufficient. MS-PWs come into play in
   two general cases:

        -i. When it is not possible, desirable or feasible to establish
            a PW control channel between the ultimate source and
            destination PEs. At a minimum PW control channel
            establishment requires knowledge of and reachability to the
            remote (ultimate) PE IP address. The local (ultimate) PE may
            not have access to this information related to topology,
            operational or security constraints.

            An example is the inter-AS L2VPN scenario where the ultimate
            PEs reside in different provider networks (ASes) and it is
            the practice to MD5-key all control traffic exchanged
            between two networks. Technically a SS-PW could be used but
            this would require MD5-keying on ALL ultimate source and
            destination PE nodes. An MS-PW allows the providers to
            confine MD5 key administration to just the PW switching
            points connecting the two domains.

            A second example might involve a single AS where the PW
            setup path between the ultimate PEs is computed by an
            external entity (i.e. client-layer routing protocol). Assume
            a full mesh of PWE3 control channels established between
            PE-A, PE-B and PE-C. A client-layer L2 connection tunneled
            through a PW is required between ultimate PE-A and PE-C. The
            external entity computes a PW setup path that passes through
            PE-B. This results in two discrete PW segments being built:
            one between PE-A and PE-B and one between PE-B and PE-C. The
            successful client-layer L2 connection between ultimate PE-A
            and ultimate PE-C requires that PE-B performs the PWE3
            switching process.




Martini, et al.                                                 [Page 5]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


            A third example involves the use of PWs in hierarchical
            IP/MPLS networks.  Access networks connected to a backbone
            use PWs to transport customer payloads between customer
            sites serviced by the same access network and up to the edge
            of the backbone where they can be terminated or switched
            onto a succeeding PW segment crossing the backbone. The use
            of PWE3 switching between the access and backbone networks
            can potentially reduce the PWE3 control channels and routing
            information processed by the access network T-PEs.

            It should be noted that PWE3 switching does not help in any
            way to reduce the amount of PW state supported by each
            access network T-PE.

       -ii. PWE3 signaling and encapsulation protocols are different.
            The ultimate PEs are connected to networks employing
            different PW signaling and encapsulation protocols. In this
            case it is not possible to use a SS-PW. A MS-PW with the
            appropriate interworking performed at the PW switching
            points can enable PW connectivity between the ultimate PEs
            in this scenario.


   There are four different signaling protocols that are defined to
   signal PWs:
        -i. Static configuration of the PW (MPLS or L2TPv3).
       -ii. LDP using FEC 128
      -iii. LDP using the generalized FEC 129
       -iv. L2TPv3


4. General Description

   A pseudo-wire (PW) is a tunnel established between two provider edge
   (PE) nodes to transport L2 PDUs across a packet switched network
   (PSN) as described in Figure 1 and in [PWE3-ARCH]. Many providers are
   looking at PWs as a means of migrating existing (or building new)
   L2VPN services (i.e.  Frame-Relay, ATM, Ethernet) on top of a PSN by
   using PWs. PWs may span multiple autonomous systems of the same or
   different provider networks. In these scenarios PW control channels
   (i.e. targeted LDP, L2TPv3) and PWs will cross AS boundaries.

   Inter-AS L2VPN functionality is currently supported and several
   techniques employing MPLS encapsulation and LDP signaling have been
   documented [2547BIS]. It is also straightforward to support the same
   inter-AS L2VPN functionality employing L2TPv3. In this document we
   define methodology to switch a PW between two PW control planes.




Martini, et al.                                                 [Page 6]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


         |<-------------- Emulated Service ---------------->|
         |                                                  |
         |          |<------- Pseudo Wire ------>|          |
         |          |                            |          |
         |          |    |<-- PSN Tunnel -->|    |          |
         |          V    V                  V    V          |
         V    AC    +----+                  +----+     AC   V
   +-----+    |     | PE1|==================| PE2|     |    +-----+
   |     |----------|............PW1.............|----------|     |
   | CE1 |    |     |    |                  |    |     |    | CE2 |
   |     |----------|............PW2.............|----------|     |
   +-----+  ^ |     |    |==================|    |     | ^  +-----+
         ^  |       +----+                  +----+     | |  ^
         |  |   Provider Edge 1         Provider Edge 2  |  |
         |  |                                            |  |
   Customer |                                            | Customer
   Edge 1   |                                            | Edge 2
            |                                            |
      native service                               native service

                     Figure 1: PWE3 Reference Model


   There are two methods for switching a PW between two PW control
   planes. In the first method (Figure 2), the two control planes
   terminate on different PEs.

                |<------------Emulated Service---------->|
                |      PSN                      PSN      |
            AC  |    |<-1->|                  |<-2->|    |  AC
            |   V    V     V                  V     V    V  |
            |   +----+     +-----+       +----+     +----+  |
   +----+   |   |    |=====|     |       |    |=====|    |  |    +----+
   |    |-------|......PW1.......|--AC1--|......PW2......|-------|    |
   | CE1|   |   |    |     |     |       |    |     |    |  |    |CE2 |
   |    |-------|......PW3.......|--AC2--|......PW4......|-------|    |
   +----+   |   |    |=====|     |       |    |=====|    |  |    +----+
        ^       +----+     +-----+       +----+     +----+       ^
        |         PE1        PE2          PE3         PE4        |
        |                     ^            ^                     |
        |                     |            |                     |
        |                  PW stitching points                   |
        |                                                        |
        |                                                        |
        |<-------------------- Emulated Service ---------------->|

            Figure 2: PW Switching using ACs Reference Model




Martini, et al.                                                 [Page 7]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


   In Figure 2, pseudo wires in two separate PSNs are stitched together
   using native service attachment circuits. PE2 and PE3 only run the
   control plane for the PSN to which they are directly attached. At PE2
   and PE3, PW1 and PW2 are connected using attachment circuit AC1,
   while PW3 and PW4 are connected using attachment circuit AC2.

           Native  |<-----------Pseudo Wire----------->|  Native
           Layer2  |                                   |  Layer2
          Service  |    |<-PSN1-->|     |<--PSN2->|    |  Service
           (AC)    V    V         V     V         V    V   (AC)
             |     +----+         +-----+         +----+     |
   +----+    |     | PE1|=========| PE2 |=========| PE3|     |    +----+
   |    |----------|........PW1.........|...PW3........|----------|    |
   | CE1|    |     |    |         |     |         |    |     |    |CE2 |
   |    |----------|........PW2.........|...PW4........|----------|    |
   +----+    |     |    |=========|     |=========|    |     |    +----+
        ^          +----+         +-----+         +----+     |    ^
        |      Provider Edge 1       ^        Provider Edge 3     |
        |       (Ultimate PE)        |         (Ultimate PE)      |
        |                            |                            |
        |                    PW switching point                   |
        |            (Optional PW adaptation function)            |
        |                                                         |
        |<------------------- Emulated Service ------------------>|

                 Figure 3: PW Control Plane Switching Reference Model

   In Figure 3 PE2 runs two separate control planes: one toward PE1, and
   one Toward PE3. The PW switching point is at PE2 which is configured
   to connect PW1 and PW3 together to complete the multi-hop PW between
   PE1 and PE3.  PW1 and PW3 MUST be of the same PW type, but PSN1 and
   PSN2 need not be the same technology. In the latter case, if the PW
   is switched to a different technology, the PEs must adapt the PDU
   encapsulation between the different PSN technologies. In the case
   where PSN1 and PSN2 are the same technology the PW PDU does not need
   to be modified, and PDUs are then switched between the pseudo-wires
   at the PW label level.

   It should be noted that it is possible to adapt one PSN technology to
   a different one, for example MPLS over an IP or GRE [MPLS-IP-GRE]
   encapsulation, but this is outside the scope of this document.
   Further, one could perform an interworking function on the PWs
   themselves at the PW switching point, allowing conversion from one PW
   type to another, but this is also outside the scope of this document.

   The pseudowire switching methodology described in this document
   assumes manual configuration of the switching point at PE2. It should
   also be noted that a PW can traverse multiple PW switching points



Martini, et al.                                                 [Page 8]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


   along it's path, and the edge PEs will not require any specific
   knowledge of how many PW switching points the PW has traversed
   (though this may be reported for troubleshooting purposes).

   In general the approach taken is to connect the individual control
   planes by passing along any signaling information immediately upon
   reception. First the PW switching point is configured to switch a
   SS-PW from a specific peer to another SS-PW destined for a different
   peer. No control messages are exchanged yet as the PW switching point
   PE does not have enough information to actually initiate the PW setup
   messages. However, if a session does not already exist, a control
   protocol (LDP/L2TP) session is setup. In this model the MS-PW setup
   is starting from the T-PE devices. Next once the T-PE is configured
   it sends the PW control setup messages. These messages are received,
   and immediately used to form the PW setup messages for the next SS-PW
   of the MS-PW. If one of the Switching PEs doesn't accept an LDP Label
   Mapping message then a Label Release message is sent back to the
   originator T-PE. A MS-PW is declared UP when all the constituent SS-
   PWs are UP.


5. PW Switching with Attachment Circuits

   In PW switching with attachment circuits, each PSN may be of a
   different type e.g. MPLS, L2TPv3. However the details of this are
   outside the scope of this document. The PWs and the attachment
   circuits MUST be of the same type e.g. ATM, Ethernet, etc.

   The PWs in each PSN are established independently, with each PSN
   being treated as a separate PWE3 domain. For example, in Figure 2 for
   case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP
   targeted session as described in [PWE3-MPLS], and at the same time a
   separate pseudo wire, PW2, is setup between PE3 and PE4. The ACs for
   PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the
   same native circuit e.g. ATM VCC, Ethernet VLAN, etc. These ACs thus
   connect the PWs in PSN1 and PSN2 together.


5.1. Aplicability

   In a client/server (PW/MPLS)relationship the performance of the
   client layer is equal to the performance of the server layer plus any
   impairments introduced by the client layer itself. Therefore it is
   not possible for the client layer to provide better performance than
   the server layer over which it is transported.

   Therefore, it is necessary to carefully consider the order in which
   different layer networks are stacked upon each other within a



Martini, et al.                                                 [Page 9]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


   'network stack' in order to provide the topmost client layer (the
   'service') with the performance that it requires.  This performance
   inheritance within a client/server relationship is vertical because
   the client layer is vertically stacked upon its server layer.

   Note: Due to this vertical performance inheritance and the different
   performance provided by, and the characteristics of, each networking
   mode it is generally advisable to stack modes that less efficiently
   provide dedicated bandwidth/performance on top of modes that more
   efficiently provide dedicated bandwidth/performance.

   When performing peer partition interworking the client layer inherits
   the performance of the server layer partition that provides the worst
   performance of all the peered server layer partitions over which the
   client layer is transported.  Therefore it is not possible for the
   client layer to receive (or provide) better performance than the
   worst performing of the peered server layer partitions over which it
   is transported.

   Therefore, it is necessary to carefully consider which server layer
   modes (and/or technologies) it is appropriate to peer with one
   another in order to provide the topmost client layer (the 'service')
   with the performance that it requires.  This is a horizontal
   performance relationship because the server layer partitions are
   peered with each other horizontally."



6. PW-MPLS to PW-MPLS Control Plane Switching

   Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted
   session as described in [PWE3-MPLS], at the same time a separate
   pseudo wire PW3 is setup to PE3. Each PW is configured independently
   on the PEs, but on PE2 pseudo wire PW1 is connected to pseudo wire
   PW3. PDUs are then switched between the pseudo-wires at the PW label
   level. Hence the data plane does not need any special knowledge of
   the specific pseudo wire type. A simple standard MPLS label swap
   operation is sufficient to connect the two PWs, and in this case the
   PW adaptation function is not used.

   This process can be repeated as many times as necessary, the only
   limitation to the number of PW switching points traversed is imposed
   by the TTL field of the PW MPLS Label. The setting of the TTL is a
   matter of local policy on the originating PE, but SHOULD be set to
   255.






Martini, et al.                                                [Page 10]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


6.1. MPLS PW Control Plane Switching

   There are three MPLS to MPLS PW control planes:
        -i. Static configuration of the PW.
       -ii. LDP using FEC 128
      -iii. LDP using the generalized FEC 129
   This results in four distinct PW switching situations that are
   significantly different, and must be considered in detail:
        -i. PW Switching between two static control planes.
       -ii. Static Control plane switching to LDP dynamic control plane.
      -iii. Two LDP control planes using the same FEC type
       -iv. LDP using FEC 128, to LDP using the generalized FEC 129


6.1.1. Static Control plane switching

   In the case of two static control planes the PW switching point MUST
   be configured to direct the MPLS packets from one PW into the other.
   There is no control protocol involved in this case. When one of the
   control planes is a simple static PW configuration and the other
   control plane is a dynamic LDP FEC 128 or generalized PW FEC, then
   the static control plane should be considered identical to an
   attachment circuit (AC) in the reference model of Figure 1. The
   switching point PE SHOULD signal the proper PW status if it detects a
   failure in sending or receiving packets over the static PW.  Because
   the PW is statically configured, the status communicated to the
   dynamic LDP PW will be limited to local interface failures. In this
   case, the PW switching point PE behaves in a very similar manner to a
   T-PE, assuming an active role. This means that the S-PE will
   immediately send the LDP Label Mapping message if the static PW is
   deemed to be UP.


6.1.2. Two LDP control planes using the same FEC type

   As stated in a section above, the PW switching point PE should assume
   an initial passive role. This means that once independent PWs are
   configured on the switching point, the LSR does not advertise the LDP
   PW FEC mapping until

   it has received at least one of the two PW LDP FECs from a remote PE.
   This is necessary because the switching point LSR does not know a
   priory what the interface parameter field in the initial FEC
   advertisement will contain.

   The PWID is a unique number between each pair of PEs. Hence Each SS-
   PW that forms an MS-PW may have a different PWID. In the case of The
   Generalized PW FEC, the AGI/SAI/TAI may have to also be different for



Martini, et al.                                                [Page 11]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


   some, or sometimes all, SS-PWs.


6.1.3. LDP using FEC 128 to LDP using the generalized FEC 129

   When a PE is using the generalized FEC 129, there are two distinct
   roles that a PE can assume: active and passive. A PE that assumes the
   active role will send the LDP PW setup message, while a passive role
   PE will simply reply to an incoming LDP PW setup message. The PW
   switching point PE, will always remain passive until a PWID FEC 128
   LDP message is received, which will cause the corresponding
   generalized PW FEC LDP message to be formed and sent. If a
   generalized FEC PW LDP message is received while the switching point
   PE is in a passive role, the corresponding PW FEC 128 LDP message
   will be formed and sent.

   PWIDs need to be mapped to the corresponding AGI/TAI/SAI and vice
   versa.  This can be accomplished by local PW switching point
   configuration, or by some other means, such as some form of auto
   discovery. Such other means are outside the scope of this document.


6.1.4. LDP PW switching point TLV

   The edge to edge PW might traverse several switching points, in
   separate administrative domains. For management and troubleshooting
   reasons it is useful to record all the switching points that the PW
   traverses. This is accomplished by using a PW switching point TLV.

   The OPTIONAL PW switching point TLV is appended to the PW FEC at each
   switching point and is encoded as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|     PW sw TLV  (0x096D)   |     PW sw TLV  Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Variable Length Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Variable Length Value                 |
   |                             "                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   [note] LDP TLV type is pending IANA approval.







Martini, et al.                                                [Page 12]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


     - PW sw TLV  Length

       Specifies the total length of all the following PW switching
       point TLV fields in octets

     - Type

       Encodes how the Value field is to be interpreted.

     - Length

       Specifies the length of the Value field in octets.

     - Value

       Octet string of Length octets that encodes information to be
       interpreted as specified by the Type field.

   PW Switching point TLV Types are assigned by IANA according the the
   process defined in the "IANA Allocations" section below.

   The PW switching Point TLV is an OPTIONAL TLV that can appear once
   for each switching point traversed.


6.1.5. PW Switching Point Sub-TLVs

   Below are details specific to PW Switching Point Sub-TLVs described
   in this document:

     - PW ID of last PW segment traversed.

       This sub-TLV type conains a PW ID in the format of the PWID
       described in [PWE3-MPLS]

     - PW Switching Point description string.

       An optional description string of text up to 80 characters long.

     - IP address of PW Switching Point.

       The IP V4 or V6 address of the PW Switching Point. This is an
       OPTIONAL Sub-TLV.
     - MH VCCV Capability Indication.







Martini, et al.                                                [Page 13]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


     - AI of last PW segment traversed.

       The Attachment Identifier of the last PW segment traversed. This
       is coded in the following format:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   AGI Type    |    Length     |      Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                    AGI  Value (contd.)                        ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   AII Type    |    Length     |      Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                   SAII  Value (contd.)                        ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   AII Type    |    Length     |      Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                   TAII Value (contd.)                         ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - L2 PW address of PW Switching Point (recomended format)

       This sub-TLV type conains a L2 PW address of PW Switching Point
       in the format described in [PWE3-ADDR]. This includes the AII
       type field , and length, as well as the L2 PW address without the
       AC ID portion (if aplicable).


6.1.6. Adaptation of Interface Parameters

   [PWE3-MPLS] defines several interface parameters, which are used by
   the Network Service Processing (NSP) to adapt the PW to the
   Attachment Circuit (AC). The interface parameters are only used at
   the end points, and MUST be passed unchanged across the PW switching
   point. However the following interface parameters MAY be modified as
   follows:

     - 0x03 Optional Interface Description string This Interface
       parameter MAY be modified, or altogether removed from the FEC
       element depending on local configuration policies.






Martini, et al.                                                [Page 14]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


     - 0x09 Fragmentation indicator This parameter MAY be inserted in
       the FEC by the switching point if it is capable of re-assembly of
       fragmented PW frames according to [PWE3-FRAG].

     - 0x0C VCCV parameter The switching point MAY not be able to
       inspect the VCCV control channel. If the new MH-VCCV sub-TLV is
       present, the VCCV parameter MUST be ignored in order to avoid
       conflicts with the new TLV.


6.1.7. Group ID

   The Group ID ( GR ID ) is used to reduce the number of status
   messages that need to be sent by the PE advertising the PW FEC. The
   GR ID has local significance only, and therefore MUST be mapped to a
   unique GR ID allocated by the PW switching point PE.


6.1.8. PW Loop Detection

   A switching point PE SHOULD check the OPTIONAL PW switching Point
   TLV, to verify if it's own IP address appears in it. If it's IP
   address appears in a received PW switching Point TLV, the PE SHOULD
   break the loop, and send a label release message with the following
   error code:
      Assignment E Description
      0x0000003A 0 "PW Loop Detected"

   [ note: error code pending IANA allocation ]


7. PW-MPLS to PW-L2TPv3 Control Plane Switching

   Both MPLS and L2TPv3 PWs may be static or dynamic. This results in
   four possibilities when switching between L2TPv3 and MPLS.

        -i. Switching between MPLS and L2TPv3 static control planes.
       -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW.
      -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW.
       -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW.











Martini, et al.                                                [Page 15]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


7.1. Static MPLS and L2TPv3 PWs

   In the case of two static control planes, the PW switching point MUST
   be configured to direct packets from one PW into the other. There is
   no control protocol involved in this case. The configuration MUST
   include which MPLS VC Label maps to which L2TPv3 Session ID (and
   associated Cookie, if present) as well as which MPLS Tunnel Label
   maps to which PE destination IP address.


7.2. Static MPLS PW and Dynamic L2TPv3 PW

   When a statically configured MPLS PW is switched to a dynamic L2TPv3
   PW, the static control plane should be considered identical to an
   attachment circuit (AC) in the reference model of Figure 1. The
   switching point PE SHOULD signal the proper PW status if it detects a
   failure in

   sending or receiving packets over the static PW. Because the PW is
   statically configured, the status communicated to the dynamic L2TPv3
   PW will be limited to local interface failures. In this case, the PW
   switching point PE behaves in a very similar manner to a T-PE,
   assuming an active role.


7.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW

   When a statically configured L2TPv3 PW is switched to a dynamic
   LDP/MPLS PW, then the static control plane should be considered
   identical to an attachment circuit (AC) in the reference model of
   Figure 1. The switching point PE SHOULD signal the proper PW status
   (via an L2TPv3 SLI message) if it detects a failure in sending or
   receiving packets over the static PW.  Because the PW is statically
   configured, the status communicated to the dynamic LDP/MPLS PW will
   be limited to local interface failures. In this case, the PW
   switching point PE behaves in a very similar manner to a T-PE,
   assuming an active role.


7.4. Dynamic LDP/MPLS and L2TPv3 PWs

   When switching between dynamic PWs, the switching point always
   assumes an initial passive role. Thus, it does not initiate an
   LDP/MPLS or L2TPv3 PW until it has received a connection request
   (Label Mapping or ICRQ) from one side of the node. Note that while
   MPLS PWs are made up of two unidirectional LSPs bonded together by
   FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a
   3-message exchange (ICRQ, ICRP and ICCN). Details of Session



Martini, et al.                                                [Page 16]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


   Establishment, Teardown, and PW Status signaling are detailed below.


7.4.1. Session Establishment

   When the PW switching point receives an L2TPv3 ICRQ message, the
   identifying AVPs included in the message are mapped to FEC
   identifiers and sent in an LDP label mapping message. Conversely, if
   an LDP Label Mapping message is received, it is either mapped to an
   ICRP message or causes an L2TPv3 session to be initiated by sending
   an ICRQ.

   Following are two example exchanges of messages between LDP and
   L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW,
   the second is a case where an MPLS T-PE initiates an MS-PW.

      PE 1 (L2TPv3)      PW Switching Node       PE3 (MPLS/LDP)

        AC "Up"
        L2TPv3 ICRQ --->
                         LDP Label Mapping  --->
                                                    AC "UP"
                                           <--- LDP Label Mapping
                   <--- L2TPv3 ICRP
        L2TPv3 ICCN  --->
      <-------------------- MH PW Established ------------------>


      PE 1 (MPLS/LDP)      PW Switching Node       PE3 (L2TPv3)

        AC "Up"
        LDP Label Mapping --->
                              L2TPv3 ICRQ  --->
                                              <--- L2TPv3 ICRP
                         <--- LDP Label Mapping
                              L2TPv3 ICCN --->
                                                   AC "Up"
      <-------------------- MH PW Established ------------------>


7.4.2. Adaptation of PW Status message

   L2TPv3 uses the SLI message to indicate a interface status change
   (such as the interface transitioning from "Up" or "Down"). MPLS/LDP
   PWs either signal this via an LDP Label Withdraw or the PW Status
   Notification message defined in section 4.4 of [PWE3-MPLS].





Martini, et al.                                                [Page 17]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


7.4.3. Session Teardown

   L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN
   message translates to a Label Withdraw message in LDP. Following are
   two example exchanges of messages between LDP and L2TPv3. The first
   is a case where an L2TPv3 T-PE initiates the termination of an MS-PW,
   the second is a case where an MPLS T-PE initiates the termination of
   an MS-PW.

   PE 1 (L2TPv3)      PW Switching Node       PE3 (MPLS/LDP)

   AC "Down"
     L2TPv3 CDN --->
                      LDP Label Withdraw  --->
                                                 AC "Down"
                                      <-- LDP Label Release

   <--------------- MH PW Data Path Down ------------------>



   PE 1 (MPLS LDP)     PW Switching Node       PE3 (L2TPv3)

   AC "Down"
   LDP Label Withdraw  --->
                           L2TPv3 CDN -->
                       <-- LDP Label Release
                                                 AC "Down"

   <---------------- MH PW Data Path Down ------------------>


7.5. Adaptation of LDP/L2TPv3 AVPs and Interface Parameters

   [PWE3-MPLS] defines several interface parameters which must be mapped
   to similar AVPs in L2TPv3 setup messages.

     * Interface MTU

       The Interface MTU parameter is mapped directly to the L2TP
       Interface MTU AVP defined in [L2TP-L2VPN]

     * Max Number of Concatenated ATM cells

       This interface parameter is mapped directly to the L2TP "ATM
       Maximum Concatenated Cells AVP" described in section 6 of [L2TP-
       ATM].




Martini, et al.                                                [Page 18]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


     * Optional Interface Description String

       This string may be carried as the "Call-Information AVP"
       described in section 2.2 of [L2TP-INFOMSG]

     * PW Type

       The PW Type defined in [PWE3-IANA] is mapped to the L2TPv3 "PW
       Type" AVP defined in [L2TPv3].

     * PW ID (FEC 128)

       For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote
       End ID" AVP defined in [L2TPv3].

     * Generalized FEC 129 SAI/TAI

       Section 4.3 of [L2TP-L2VPN] defines how to encode the SAI and TAI
       parameters. These can be mapped directly.

   Other interface parameter mappings will either be defined in a future
   version of this document, or are unsupported when switching between
   LDP/MPLS and L2TPv3 PWs.


7.6. Switching Point TLV in L2TPv3

   When translating between LDP and L2TPv3 control messages, the PW
   Switching Point TLV described earlier in this document is carried in
   a single variable length L2TP AVP present in the ICRQ, ICRP messages,
   and optionally in the ICCN message.

   The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The
   AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of
   the AVP is 6 plus the length of the series of Switching Point sub-
   TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory
   (the L2TP AVP M-bit MUST be 0).


7.7. L2TPv3 and MPLS PW Data Plane

   When switching between an MPLS and L2TP PW, packets are sent in their
   entirety from one PW to the other, replacing the MPLS label stack
   with the L2TPv3 and IP header or vice versa. There are some
   situations where an additional amount of interworking must be
   provided between the two data planes at the PW switching node.





Martini, et al.                                                [Page 19]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


7.7.1. PWE3 Payload Convergence and Sequencing

   Section 5.4 of [PWE3-ARCH] discusses the purpose of the various shim
   headers necessary for enabling a pseudowire over an IP or MPLS PSN.
   For L2TPv3, the Payload Convergence and Sequencing function is
   carried out via the Default L2-Specific Sublayer defined in [L2TPv3].
   For MPLS, these two functions (together with PSN Convergence) are
   carried out via the MPLS Control Word. Since these functions are
   different between MPLS and L2TPv3, interworking between the two may
   be necessary.

   The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers
   which in some cases are not necessary to be present at all. For
   example, an Ethernet PW with sequencing disabled will generally not
   require an MPLS Control Word or L2TP Default L2-Specific Sublayer to
   be present at all. In this case, Ethernet frames are simply sent from
   one PW to the other without any modification beyond the MPLS and
   L2TP/IP encapsulation and decapsulation.

   The following section offers guidelines for how to interwork between
   L2TP and MPLS for those cases where the Payload Convergence,
   Sequencing, or PSN Convergence functions are necessary on one or both
   sides of the switching node.


7.7.2. Mapping

   The MPLS Control Word consists of (from left to right):

        -i. These bits are always zero in MPLS are not necessary to be
            mapped to L2TP.

       -ii. These six bits may be used for Payload Convergence depending
            on the PW type. For ATM, the first four of these bits are
            defined in [PWE3-ATM]. These map directly to the bits
            defined in [L2TP-ATM]. For Frame Relay, these bits indicate
            how to set the bits in the Frame Relay header which must be
            regenerated for L2TP as it carries the Frame Relay header
            intact.

      -iii. L2TP determines its payload length from IP. Thus, this
            Length field need not be carried directly to L2TP. This
            Length field will have to be calculated and inserted for
            MPLS when necessary.







Martini, et al.                                                [Page 20]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


       -iv. The Default L2-Specific Sublayer has a sequence number with
            different semantics than that of the MPLS Control Word. This
            difference eliminates the possibility of supporting
            sequencing across the MS-PW by simply carrying the sequence
            number through the switching point transparently. As such,
            sequence numbers MAY be supported by checking the sequence
            numbers of packets arriving at the switching point and
            regenerating a new sequence number in the proper format for
            the PW on egress. If this type of sequence interworking at
            the switching node is not supported, and a T-PE requests
            sequencing of all packets via the L2TP control channel
            during session setup, the switching node SHOULD NOT allow
            the session to be established by sending a CDN message with
            Result Code set to 17 "sequencing not supported" (subject to
            IANA Assignment).


8. Operation And Management

8.1. Extensions to VCCV to Support Switched PWs

   Single-hop pseudowires are signaled using the FEC 128 or FEC 129
   interface as described in [VCCV].  Although VCCV can be run between
   each PE device supporting a particular segment, no support is
   available for VCCV across switching points, nor is there support for
   signaling this capability in the existing protocol. Further
   extentions are also possible for switch pseudowire VCCV such as VCCV
   providing a switch point tracing function. Extensions to the existing
   protocol are required in order to support switched pseudowires with
   these capabilities. These extensions are explained below.


8.2. PW-MPLS to PW-MPLS OAM Data Plane Indication

   The [PW-CW] defines an PW Associated Channel, which is specified in
   [VCCV] as follows for single-hop pseudowires:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|  Reserved = 0 |         Channel Type = 0      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Multi-hop pseudowire OAM is indicated using the following PW header:






Martini, et al.                                                [Page 21]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|  0x00 |  Reserved = 0 |         Channel Type = 0x01   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MH-TTL        |            MH-VCCV sub-TLV                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   This header MUST be used for end-to-end VCCV traffic. An operator can
   then use this header to stimulate multihop VCCV operations as
   described below.

   Field     Length     Description MH-TTL    8 bits     Describes the
   number of switch points.
                        When the field is set to 0, the packet
                        should not be forwarded.

   ----- note TTL processing needs to be clearly stated.  MH-VCCV sub-
   TLV ------ note what is the above ?

8.3. Signal OAM Capabilities for Switched Pseudo Wires

   A PW Switching Point TLV includes a sub-TLV with type 0x04 in order
   to indicate multihop OAM capabilities to each switching point. This
   new sub-TLV MUST be appended to the PW Switching Point TLV to include
   MH-VCCV capability indication. This sub-TLV MUST be examined by each
   switching point and modified according to the rules outlined below.


8.3.1. OAM Capability for MH PWs Demultiplexed using MPLS

   The MH-VCCV parameter ID is defined as follows in [PWE3IANA]:

        Parameter ID   Length     Description
          0x0c           4           VCCV


   The format of the VCCV parameter field is as follows:

      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 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0x0c     |       0x04    |   CC Types    |   CV Types    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Martini, et al.                                                [Page 22]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


8.3.2. OAM Capability for MH PWs Demultiplexed using L2TPv3

   TBD


8.4. Tracing Switched PW Switch Points Using MH-VCCV

   Although the signaling of switched PWs includes functionality to
   record all switch points traversed by a particular switched
   pseudowire, this information is limited to the control plane.
   Specifically, this is the information which is then used to program
   the actual switching hardware. In an effort to provide explicit
   diagnostic capability of the data plane used by the switched
   pseudowire, it is necessary in some cases to compare the control and
   data planes used by a particular switched pseudowire. In these cases,
   it is possible to trace the pseudowire switch points by sending
   single-hop VCCV messages with TTL described above in the MH VCCV
   header, and increasing TTL values. This algorithm can be used to
   "walk" across the network of switchpoints until the ultimate PE is
   reached.


8.5. Mapping Switched Pseudo Wire Status

   In the PW switching with attachment circuits case (Figure 2), PW
   status messages indicating PW or attachment circuit faults SHOULD be
   mapped to fault indications or OAM messages on the connecting AC as
   defined in [PW-MSG-MAP]. If the AC connecting two PWs crosses an
   administrative boundary, then the manner in which those OAM messages
   are treated at the boundary is out of scope of this draft.

   In the PW control plane switching case (Figure 3), there is no
   attachment circuit at the PW switching point, but the two PWs are
   connected together. Similarly, the status of the PWs are forwarded
   unchanged from one PW to the other by the control plane switching
   function. However, it may sometimes be necessary to communicate
   status of one of the locally attached SS-PW at a PW switching point.
   For LDP this can be accomplished by sending an LDP notification
   message containing the PW status TLV, as well as an OPTIONAL PW
   switching point TLV.











Martini, et al.                                                [Page 23]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification   (0x0001)   |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Message ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1| Status (0x0300)           |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1|                 Status Code=0x00000028                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID=0                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Message Type=0           |      PW Status TLV            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PW Status TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PW Status TLV         |            PWId FEC           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                 PWId FEC or Generalized ID FEC                |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|     PW sw TLV  (0x096D)   |     PW sw TLV  Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Variable Length Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Only one PW switching point TLV can be present in this message. This
   message is then relayed by each PW switching point unchanged. The T-
   PE decodes the status message and the included PW switching point TLV
   to detect where exactly the fault occurred. At the T-PE if there is
   no PW switching point TLV included in the LDP status notification
   then the status message can be assumed to have originated at the
   remote T-PE. It should also be noted that once a PW status
   notification message is initiated at a PW switching point, any
   further status message received from an upstream neighbor is
   processed locally and not forwarded until the PW switching point
   original status error state is cleared. When a PW status notification
   message, for a particular PW, is received at the S-PE, the
   appropriate PW status notification MUST be send toward both remote
   S-PEs or T-PEs attached to the PW.






Martini, et al.                                                [Page 24]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


8.6. Pseudowire Status Negotiation Procedures

   Pseudowire Status signaling methodology, defined in [PWE3-MPLS],
   SHOULD be transparent to the switching point.


8.7. Status Dampening

   When the PW control plane switching methodology is used to cross an
   administrative boundary it might be necessary to prevent excessive
   status signaling changes from being propagated across the
   administrative boundary.  This can be achieved by using a similar
   method as commonly employed for the BGP protocol route advertisement
   dampening. The details of this OPTIONAL algorithm are a matter of
   implementation, and are outside the scope of this document.


9. Peering Between Autonomous Systems

   The procedures outlined in this document can be employed to provision
   and manage MS-PWs crossing AS boundaries.

   The use of more advanced mechanisms involving auto-discovery and
   ordered PWE3 MS-PW signaling will be covered in a separate document.


10. Security Considerations

   This document specifies the LDP and L2TPv3 extensions that are needed
   for setting up and maintaining Pseudowires. The purpose of setting up
   Pseudowires is to enable layer 2 frames to be encapsulated and
   transmitted from one end of a Pseudowire to the other. Therefore we
   treat the security considerations for both the data plane and the
   control plane.


10.1. Data Plane Security

   Data plane security consideration as discussed in [PWE3-MPLS],
   [L2TPv3], and [PWE3-ARCH] apply to this extension without any
   changes.










Martini, et al.                                                [Page 25]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


10.2. Control Protocol Security

   General security considerations with regard to the use of LDP are
   specified in section 5 of RFC 3036. Security considerations with
   regard to the L2TPv3 control plane are specified in [L2TPv3]. These
   considerations apply as well to the case where LDP or L2TPv3 is used
   to set up PWs.

   A Pseudowire connects two attachment circuits. It is important to
   make sure that LDP connections are not arbitrarily accepted from
   anywhere, or else a local attachment circuit might get connected to
   an arbitrary remote attachment circuit. Therefore an incoming session
   request MUST NOT be accepted unless its IP source address is known to
   be the source of an "eligible" peer. The set of eligible peers could
   be pre-configured (either as a list of IP addresses, or as a list of
   address/mask combinations), or it could be discovered dynamically via
   an auto-discovery protocol which is itself trusted. (Obviously if the
   auto-discovery protocol were not trusted, the set of "eligible peers"
   it produces could not be trusted.)

   Even if a connection request appears to come from an eligible peer,
   its source address may have been spoofed.  So some means of
   preventing source address spoofing must be in place.  For example, if
   all the eligible peers are in the same network, source address
   filtering at the border routers of that network could eliminate the
   possibility of source address spoofing.

   For a greater degree of security, the LDP MD5 authentication key
   option, as described in section 2.9 of RFC 3036, or the Control
   Message Authentication option of [L2TPv3] MAY be used.  This provides
   integrity and authentication for the control messages, and eliminates
   the possibility of source address spoofing.  Use of the message
   authentication option does not provide privacy, but privacy of
   control messages are not usually considered to be highly urgent.
   Both the LDP and L2TPv3 message authentication options rely on the
   configuration of pre-shared keys, making it difficult to deploy when
   the set of eligible neighbors is determined by an auto-configuration
   protocol.

   When the Generalized ID FEC Element is used, it is possible that a
   particular peer may be one of the eligible peers, but may not be the
   right one to connect to the particular attachment circuit identified
   by the particular instance of the Generalized ID FEC element.
   However, given that the peer is known to be one of the eligible peers
   (as discussed above), this would be the result of a configuration
   error, rather than a security problem.  Nevertheless, it may be
   advisable for a PE to associate each of its local attachment circuits
   with a set of eligible peers, rather than having just a single set of



Martini, et al.                                                [Page 26]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


   eligible peers associated with the PE as a whole.


11. IANA Considerations

11.1. Channel

   The Channel Type codepoint is defined in [PW-CW], and an IANA
   registry was requested in [VCCV]. This draft further requests the
   following code point to be assigned to that registry. 0x01 OAM
   Indication For Multihop Pseudowires (MH-VCCV)


11.2. L2TPv3 AVP

   This document uses a ne L2TP parameter, IANA already maintains a
   registry of name "Control Message Attribute Value Pair" defined by
   [RFC3438]. The following new values are required:

   TBA-L2TP-AVP-1 - PW Switching Point AVP


11.3. LDP TLV TYPE

   This document uses several new LDP TLV types, IANA already maintains
   a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The
   following value is suggested for assignment:

      TLV type  Description
       0x096D   Pseudo Wire Switching TLV


11.4. LDP Status Codes

   This document uses several new LDP status codes, IANA already
   maintains a registry of name "STATUS CODE NAME SPACE" defined by
   RFC3036. The following value is suggested for assignment:

      Assignment E Description
      0x0000003A 0 "PW Loop Detected"











Martini, et al.                                                [Page 27]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


11.5. L2TPv3 Result Codes

   This document uses several new LDP status codes, IANA already
   maintains a registry of name "L2TPv3 Result Codes" defined by
   RFCxxxx. The following value is suggested for assignment:

      Assignment  Description
          17      "sequencing not supported"


11.6. New IANA Registries

   IANA needs to set up a registry of "PW Switching Point TLV Type".
   These are 8-bit values. Types value 1 through 3 are defined in this
   document.  Type values 4 through 64 are to be assigned by IANA using
   the "Expert Review" policy defined in RFC2434. AGI Type values 65
   through 127, 0 and 255 are to be allocated using the IETF consensus
   policy defined in [RFC2434].  AGI types values 128 through 254 are
   reserved for vendor proprietary extensions and are to be assigned by
   IANA, using the "First Come First Served" policy defined in RFC2434.

   The Type Values are assigned as follows:
   Type  Length    Description

   0x01     4       PW ID of last PW segment traversed
   0x02  variable   PW Switching Point description string
   0x03    4/16     IP address of PW Switching Point
   0x04  variable   MH VCCV Capability Indication
   0x05  variable   AI of last PW segment traversed
   0x06  variable   L2 PW address of PW Switching Point (recomended format)



12. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this



Martini, et al.                                                [Page 28]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


13. Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


14. Acknowledgments

   The authors wish to acknowledge the contributions of Wei Luo, and
   Skip Booth.


15. Normative References

   [PWE3-MPLS] "Transport of Layer 2 Frames Over MPLS", Martini, L.,
         et al.,draft-ietf-pwe3-control-protocol-16.txt,
        ( work in progress ), May 2005.

   [2547BIS] "BGP/MPLS IP VPNs", Rosen, E, Rekhter, Y.
        draft-ietf-l3vpn-rfc2547bis-03.txt ( work in progress ),
        October 2004.

   [L2TPv3] "Layer Two Tunneling Protocol (Version 3)", J. Lau,
        M. Townsley, I. Goyret, RFC3931

   [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection
        Verification (VCCV)", Internet Draft



Martini, et al.                                                [Page 29]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


        <draft-ietf-pwe3-vccv-08.txt>, October 2005. (work in progress)

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
        IANA Considerations section in RFCs", BCP 26, RFC 2434, October
        1998.

   [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
        Languages", BCP 18, RFC 2277, January 1998.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

   [BCP79] S. Bradner, Ed., "Intellectual Property Rights in IETF
        Technology", BCP 79, RFC 3979, March 2005.

   [BCP78] S. Bradner, Ed., "IETF Rights in Contributions",
        BCP 78, RFC 3978, March 2005.

   [PW-ADDR] C. Metz, L. Martini, F. Balus, J. Sugimoto, "AII Types
        for Aggregation" draft-metz-aii-aggregate-01.txt, (work in
        progress), October 2005


16. Informative References

   [MPLS-IP-GRE] "Encapsulating MPLS in IP or Generic
        Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y.
        draft-ietf-mpls-in-ip-or-gre-08.txt, ( work in progress ),
        December 2004.

   [PWE3-ARCH] "PWE3 Architecture" Bryant, et al.,
        draft-ietf-pwe3-arch-07.txt ( work in progress ), June 2003.

   [PWE3-FRAG] "PWE3 Fragmentation and Reassembly", A. Malis,
        W. M. Townsley, draft-ietf-pwe3-fragmentation-05.txt
        ( work in progress ) February 2004

   [PWE-IANA] "IANA Allocations for pseudo Wire Edge to
        Edge Emulation (PWE3)" Martini, Townsley,
        draft-ietf-pwe3-iana-allocation-04.txt ( work in progress ),
        April 2004

   [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, Wei,
        draft-ietf-l2tpext-l2vpn-00.txt, ( work in progress ), Jan 2004

   [L2TP-INFOMSG] "L2TP Call Information Messages", Mistretta,
        Goyret, McGill, Townsley, draft-mistretta-l2tp-infomsg-02.txt,
        ( work in progress ), July 2004



Martini, et al.                                                [Page 30]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006


   [L2TP-ATM] "ATM Pseudo-Wire Extensions for L2TP", Singh,
        Townsley, Lau, draft-ietf-l2tpext-pwe3-atm-00.txt,
        ( work in progress ), March 2004.

   [PWE3-ATM] "Encapsulation Methods for Transport of ATM
        Over IP and MPLS Networks", Martini, Rosen, Bocci,
        "draft-ietf-pwe3-atm-encap-05.txt", ( work in progress ),
        April 2004.

   [RFC3438]  W. M. Townsley, "Layer Two Tunneling Protocol
        (L2TP) Internet"

   [BCP68] Assigned Numbers Authority (IANA) Considerations
        Update", RFC 3438, BCP 68, November 2002.

   [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al,
        draft-ietf-pwe3-oam-msg-map-02.txt, ( work in progress ),
        February 2005


17. Author Information


   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112
   e-mail: lmartini@cisco.com


   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA 01719
   e-mail: tnadeau@cisco.com


   Chris Metz
   Cisco Systems, Inc.
   e-mail: chmetz@cisco.com











Martini, et al.                                                [Page 31]

Internet Draft    draft-ietf-pwe3-segmented-pw-02.txt         March 2006



   Mike Duckett
   Bellsouth
   Lindbergh Center
   D481
   575 Morosgo Dr
   Atlanta, GA  30324
   e-mail: mduckett@bellsouth.net


   Vasile Radoaca
   e-mail: radoaca@hotmail.com


   Matthew Bocci
   Alcatel
   Grove House, Waltham Road Rd
   White Waltham, Berks, UK. SL6 3TN
   e-mail: matthew.bocci@alcatel.co.uk


   Florin Balus
   Nortel Networks
   3500 Carling Ave.
   Ottawa, Ontario, CANADA
   e-mail: balus@nortel.com

























Martini, et al.                                                [Page 32]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/