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

Versions: 00 01 02 03 04 05 06 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 RFC 7267

PWE3 Working Group                                    Luca Martini (Ed.)
Internet Draft                                        Cisco Systems Inc.
Expires: January 2009                                Matthew Bocci (Ed.)
                                                          Alcatel-Lucent
                                                      Florin Balus (Ed.)
                                                          Alcatel-Lucent

                                                               July 2008



            Dynamic Placement of Multi Segment Pseudo Wires


                  draft-ietf-pwe3-dynamic-ms-pw-08.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/1id-abstracts.html

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

Abstract

   There is a requirement for service providers to be able to extend the
   reach of pseudo wires (PW) across multiple Packet Switched Network
   domains. A Multi-Segment PW is defined as a set of two or more
   contiguous PW segments that behave and function as a single point-
   to-point PW. This document describes extensions to the PW control
   protocol to dynamically place the segments of the multi segment
   pseudo wire among a set of Provider Edge (PE) routers.



Martini, et al.                                                 [Page 1]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008




Table of Contents

    1        Specification of Requirements  ........................   3
    2        Major Co-authors  .....................................   3
    3        Acknowledgements  .....................................   3
    4        Introduction  .........................................   3
    4.1      Scope  ................................................   3
    4.2      Terminology  ..........................................   4
    4.3      Architecture Overview  ................................   4
    5        Applicability  ........................................   6
    5.1      Requirements Addressed  ...............................   6
    5.2      Changes to Existing PW Signaling  .....................   6
    6        PW layer 2 addressing  ................................   6
    6.1      Attachment Circuit Addressing  ........................   7
    6.2      S-PE addressing  ......................................   7
    7        Dynamic placement of MS-PWs  ..........................   8
    7.1      Pseudo wire routing procedures  .......................   8
    7.1.1    AII PW routing table Lookup aggregation rules  ........   8
    7.1.2    PW Static Route  ......................................   9
    7.1.3    Dynamic advertisement with BGP  .......................   9
    7.2      LDP Signaling  ........................................  10
    7.2.1    MS-PW Bandwidth Signaling  ............................  10
    7.2.2    Active/Passive T-PE Election Procedure  ...............  12
    7.2.3    Detailed Signaling Procedures  ........................  12
    7.2.4    Support for Explicit PW Path  .........................  13
    8        Failure Handling Procedures  ..........................  14
    8.1      PSN Failures  .........................................  14
    8.2      S-PE Reachability Failures  ...........................  14
    9        Operations and Maintenance (OAM)  .....................  14
   10        Security Considerations  ..............................  15
   11        IANA Considerations  ..................................  15
   11.1      LDP Status Codes  .....................................  15
   11.2      BGP SAFI  .............................................  16
   12        Full Copyright Statement  .............................  16
   13        Intellectual Property Statement  ......................  16
   14        Normative References  .................................  17
   15        Informative References  ...............................  17
   16        Author Information  ...................................  18











Martini, et al.                                                 [Page 2]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


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. Major Co-authors

   The editors gratefully acknowledge the following additional co-
   authors:  Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan,
   Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff
   Sugimoto.


3. Acknowledgements

   The editors also gratefully acknowledge the input of the following
   people:  Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile
   Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada.


4. Introduction

4.1. Scope

   [MS-REQ] describes the service provider requirements for extending
   the reach of pseudo-wires across multiple PSN domains. This is
   achieved using a Multi-segment Pseudo-Wire (MS-PW). A MS-PW is
   defined as a set of two or more contiguous PW segments that behave
   and function as a single point-to-point PW. This architecture is
   described in [MS-ARCH].

   The procedures for establishing PWs that extend across a single PWE3
   domain are described in [RFC4447], while procedures for setting up
   PWs across multiple domains, or control planes are described in [PW-
   SEG].

   The purpose of this draft is to specify extensions to the PWE3
   control protocol [RFC4447], and [PW-SEG] procedures, to enable
   multi-segment PWs to be automatically placed. The proposed procedures
   follow the guidelines defined in [RFC5036] and enable the reuse of
   existing TLVs, and procedures defined for SS-PWs in [RFC4447].








Martini, et al.                                                 [Page 3]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


4.2. Terminology

   [MS-ARCH] provides terminology for multi-segment pseudo wires.

   This document defines the following additional terms:

     - Source Terminating PE (ST-PE). A Terminating PE (T-PE), which
       assumes the active signaling role and initiates the signaling for
       multi-segment PW.
     - Target Terminating PE (TT-PE). A Terminating PE (T-PE) that
       assumes the passive signaling role. It waits and responds to the
       multi-segment PW signaling message in the reverse direction.
     - Forward Direction: ST-PE to TT-PE.
     - Reverse Direction: TT-PE to ST-PE
     - Forwarding Direction: Direction of control plane, signaling flow
     - Pseudo wire Routing (PW routing). The dynamic placement of SS-PWs
       that compose an MS-PW, as well as the automatic selection of S-
       PEs.



4.3. Architecture Overview

   The following figure describes the reference models which are derived
   from [MS-ARCH] to support PW emulated services across multi-segment
   PWs.

























Martini, et al.                                                 [Page 4]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008



       Native   |<-------------Pseudo Wire----------->|  Native
       Service  |                                     |  Service
        (AC)    |     |<-PSN1-->|     |<-PSN2-->|     |   (AC)
          |     V     V         V     V         V     V     |
          |     +-----+         +-----+         +-----+
   +----+ |     |T-PE1|=========|S-PE1|=========|T-PE2|     |    +----+
   |    |-------|.....PW.Seg't1........PW Seg't3......|----------|    |
   | CE1| |     |     |         |     |         |     |     |    |CE2 |
   |    |-------|.....PW.Seg't2.......|PW Seg't4......|----------|    |
   +----+ |     |     |=========|     |=========|     |     |    +----+
        ^       +-----+         +-----+         +-----+          ^
        |   Provider Edge 1        ^        Provider Edge 2      |
        |                          |                             |
        |                          |                             |
        |                  PW switching point                    |
        |                                                        |
        |<---------------- Emulated Service -------------------->|


                 Figure 1: PW switching Reference Model


   Figure 1 shows the architecture for a simple multi-segment case. T-
   PE1 and T-PE2 provide PWE3 to CE1 and CE2. These PEs reside in
   different PSNs. A PSN tunnel extends from T-PE1 to S-PE1 across PSN1,
   and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PWs
   are used to connect the attachment circuits (ACs) attached to T-PE1
   to the corresponding AC attached to T-PE2. A PW on the tunnel across
   PSN1 is connected to a PW in the tunnel across PSN2 at S-PE1 to
   complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1
   is therefore the PW switching point and will be referred to as the
   switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are
   segments of the same MS-PW while PW Segment 2 and PW Segment 4 are
   segments of another MS-PW. PW segments of the same MS-PW (e.g., PW
   segment 1 and PW segment 3) MUST be of the same PW type, and PSN
   tunnels (e.g., PSN1 and PSN2) can be the same or different
   technology. An S-PE switches an MS-PW from one segment to another
   based on the PW identifiers. ( PWid , or AII ) How the Pw PDUs are
   switched at the S-PE depends on the PSN tunnel technology: in case of
   an MPLS PSN to another MPLS PSN PW switching the operation is a
   standard MPLS label switch operation.

   Note that although Figure 1 only shows a single S-PE, a PW may
   transit more one S-PE along its path. For instance, in the multi-
   provider case, there can be an S-PE at the border of one provider
   domain and another S-PE at the border of the other provider domain.




Martini, et al.                                                 [Page 5]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


5. Applicability

   In this document we describe the case where the PSNs carrying the
   SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions
   with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are
   left for further study.


5.1. Requirements Addressed

   Specifically the following requirements are addressed [MS-REQ]:
     - Dynamic End-to-end Signaling
     - Scalability and Inter-domain Signaling and Routing
     - Minimal number of provisioning touches (provisioning only at the
       T-PEs)
     - Same set of T-PEs/S-PEs for both directions of a MS-PWs
     - QoS Signaling, Call Admission Control
     - Resiliency
     - End-to-end negotiation of OAM Capability


5.2. Changes to Existing PW Signaling

   The procedures described in this document make use of existing LDP
   TLVs and related PW signaling procedures described in [RFC4447] and
   [PW-SEG]. Only an optional Bandwidth TLV is added to address the QoS
   Signaling requirements (see "MS-PW Next Hop Bandwidth Signaling"
   section for details).


6. PW layer 2 addressing

   Single segment pseudo wires on an MPLS PSN use Attachment circuit
   identifiers for a PW using FEC 129. In the case of an automatically
   placed MS-PW, there is a requirement to have individual global
   addresses assigned to PW attachment circuits, for reachability , and
   manageability of the PW.  Referencing figure 1 above, individual
   globally unique addresses MUST be allocated to all the ACs , and S-
   PEs composing an MS-PW.












Martini, et al.                                                 [Page 6]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


6.1. Attachment Circuit Addressing

   The attachment circuit addressing is derived from [RFC5003] AII type
   2 shown here:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AII Type=02  |    Length     |        Global ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Global ID (contd.)      |        Prefix                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Prefix (contd.)         |        AC ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      AC ID                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Implementations of the following procedure MUST interpret the AII
   type to determine the meaning of the address format of the AII,
   irrespective of the number of segments in the MS-PW.

   A unique combination Global ID, Prefix, and AC ID parts of the AII
   type 2 will be assigned to each AC. In general the same global ID and
   prefix will be assigned for all ACs belonging to the same T-PE,
   however this is not a strict requirement. A particular T-PE might
   have more than one prefix assigned to it, and likewise a fully
   qualified AII with the same Global ID/Prefix but different AC IDs
   might belong to different T-PEs.

   For the purpose of MS-PW the AII MUST be globally unique across all
   interconnected PW domains.


6.2. S-PE addressing

   The T-PE may elect to select a known specific path along a set of S-
   PEs for a specific PW. This requires that each S-PE be uniquely
   addressable in terms of pseudo wires. For this purpose at least one
   AI address of the format similar to AII type 2 [RFC5003] composed of
   the Global ID, and Prefix part only MUST be assigned to each S-PE.










Martini, et al.                                                 [Page 7]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


7. Dynamic placement of MS-PWs

   [PW-SEG] describes a procedure for connecting multiple pseudo wires
   together. This procedure requires each S-PE to be manually configured
   with the information required to terminate and initiate the SS-PW
   part of the MS-PW. The procedures in the following sections describe
   an method to extend [PW-SEG] by allowing the automatic selection of
   pre-defined S-PEs, and automatically setting up a MS-PW between two
   T-PEs.


7.1. Pseudo wire routing procedures

   The AII type 2 described above contains a Global ID, Prefix, and AC
   ID. The TAII is used by S-PEs to determine the next SS-PW destination
   for LDP signaling.

   Once an S-PE receives a MS-PW label mapping message containing a TAII
   with an AII that is not locally present, the S-PE performs a lookup
   in a local Layer 2 AII PW routing table. If this lookup results in an
   IP address of the next PE that advertised reachability information
   for the AII in question, then the S-PE will initiate the necessary
   LDP messaging procedure for setting up the next PW segment. If the
   AII PW routing table lookup does not result in a IP address of the
   next PE, the destination AII has become unreachable, and the PW MUST
   fail to setup. In this case the next PW segment is considered
   unprovisioned, and a label release MUST be returned to the T-PE with
   a status message of "AII Unreachable".

   If the TAI of a MS-PW label mapping message, received by a PE,
   contains the prefix of a locally provisioned prefix on that PE, but
   an AC ID that is not provisioned, then the LDP liberal label
   retention procedures apply, and the label mapping message is
   retained.

   To allow for dynamic end-to-end signaling of MS-PWs, information must
   be present in S-PEs to support the determination of the next PW
   signaling hop.  Such information can be provisioned (static route
   equivalent) on each S-PE system or disseminated via regular routing
   protocols (e.g. BGP).


7.1.1. AII PW routing table Lookup aggregation rules

   All PEs capable of dynamic multi segment pseudowire path selection,
   must build a PW routing table to be used for PW next hop selection.

   The PW addressing scheme (AII type 2 in [RFC5003]) consists of a



Martini, et al.                                                 [Page 8]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


   Global Id, a 32 bit prefix and a 32 bit Attachment Circuit ID.

   An aggregation scheme similar with the one used for classless IPv4
   addresses can be employed. An (8 bits) length mask is specified as a
   number ranging from 0 to 96 that indicates which Most Significant
   Bits (MSB) are relevant in the address field when performing the PW
   address matching algorithm.

    0        31 32    63 64    95 (bits)
   +-----------+--------+--------+
   | Global ID | Prefix | AC ID  |
   +-----------+--------+--------+


   During the signaling phase, the content of the (fully qualified) TAII
   type 2 field from the FEC129 TLV is compared against routes from the
   PW Routing table. Similar with the IPv4 case, the route with the
   longest match is selected, determining the next signaling hop and
   implicitly the next PW Segment to be signaled.


7.1.2. PW Static Route

   For the purpose of determining the next signaling hop for a segment
   of the pseudo wire, the PEs MAY be provisioned with fixed route
   entries in the PW next hop routing table. The static PW entries will
   follow all the addressing rules and aggregation rules described in
   the previous sections.  The most common use of PW static provisioned
   routes is this example of the "default" route entry as follows:

   Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling
   Hop = S-PE1


7.1.3. Dynamic advertisement with BGP

   Any suitable routing protocol capable of carrying external routing
   information may be used to propagate MS-PW path information among S-
   PE, and T-PE. However, T-PE, and S-PEs, MAY choose to use Boundary
   Gateway Protocol (BGP) [RFC2858] to propagate PW address information
   throughout the PSN.

   Contrary to other l2vpn signaling methods that use BGP [L2-
   SIGNALING], in the case of the dynamically placed MS-PW if the source
   T-PE knows a priori (by provisioning) the address of the terminating
   T-PE. Hence there is no need to advertise a "fully qualified" 96 bit
   address on a per PW Attachment Circuit basis. Only the T-PE Global
   ID, Prefix, and prefix length needs to be advertised as part of well



Martini, et al.                                                 [Page 9]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


   known BGP procedures - see [RFC2858].

   As PW Endpoints are provisioned in the T-PEs. The ST-PE will use this
   information to obtain the first S-PE hop (i.e., first BGP next hop)
   to where the first PW segment will be established. Any subsequent S-
   PEs will use the same information (i.e. the next BGP next-hop(s)) to
   obtain the next-signaling-hop(s) on the path to the TT-PE.

   The PW dynamic path NLRI is advertised in BGP UPDATE messages using
   the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC2858]. The [AFI,
   SAFI] value pair used to identify this NLRI is (AFI=25, SAFI=6
   (pending IANA allocation)).

   The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as
   an IPv4 address, whenever the length of the NextHop address is 4
   octets, and as a IPv6 address, whenever the length of the NextHop
   address is 16 octets.

   The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
   of 0 to 96 bits encoded as defined in section 4 of [RFC2858].

   This prefix is structured as follows:

    0        31 32    63 64    95 (bits)
   +-----------+--------+--------+
   | Global ID | Prefix | AC ID  |
   +-----------+--------+--------+


   Except for the default PW route, which is encoded as a 0 length
   prefix, the minimum prefix length is 32 bits. Prefix lengths of 65 to
   95 are invalid as the AC ID field cannot be aggregated.


7.2. LDP Signaling

   The LDP signaling procedures are described in [RFC4447] and expanded
   in [PW-SEG]. No new LDP Signaling components are required for setting
   up a dynamically placed MS-PW. However some optional signaling
   extensions are described below.


7.2.1. MS-PW Bandwidth Signaling

   In the SS-PW case the PW QoS requirements may easily be met by
   selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS
   requirements. However in the case of an automatically placed MS-PW
   the QoS requirements for a SS-PW not initiating on a T-PE MAY need to



Martini, et al.                                                [Page 10]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


   be indicated along with the MS-PW addressing. This is accomplished by
   including an OPTIONAL PW Bandwidth TLV.  The PW Bandwidth TLV is
   specified 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 BW  TLV  (0x096E)   |         TLV  Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Forward SENDER_TSPEC                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Reverse SENDER_TSPEC                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The complete definitions of the content of the SENDER_TSPEC objects
   are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to
   the data path in the direction of ST-PE to TT-PE. The reverse
   SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE.

   In the forward direction, after a next hop selection is determined, a
   T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine
   an appropriate PSN tunnel towards the next signaling hop. If such a
   tunnel exists, the MS-PW signaling procedures are invoked with the
   inclusion of the PW Bandwidth TLV. When the PE searches for a PSN
   tunnel, any tunnel which points to a next hop equivalent to the next
   hop selected will be included in the search.(The LDP address TLV is
   used to determine the next hop equivalence)

   When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is
   selected, the S/T-PE MUST request the appropriate resources from the
   PSN.  The resources described in the reverse SENDER_TSPEC are
   allocated from the PSN toward the originator of the message or
   previous hop. When resources are allocated from the PSN for a
   specific PW, then the PSN SHOULD account for the PW usage of the
   resources.

   In the case where PSN resources towards the previous hop are not
   available the following procedure MUST be followed:
        -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to
            the PSN tunnel.
       -ii. The S-PE MAY attempt to setup another PSN tunnel to
            accommodate the new PW QoS requirements.
      -iii. If the S-PE cannot get enough resources to setup the segment
            in the MS-PW a label release MUST be returned to the
            previous hop with a status message of "Bandwidth resources
            unavailable"




Martini, et al.                                                [Page 11]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


   In the latter case, the T-PE receiving the status message MUST also
   withdraw the corresponding PW label mapping for the opposite
   direction if it has already been successfully setup.

   If an ST-PE receives a label mapping message the following procedure
   MUST be followed:

   If the ST-PE has already sent a label mapping message for this PW
   then the ST-PE must check that this label mapping message originated
   from the same LDP peer to which the corresponding label mapping
   message for this particular PW was sent. If it is the same peer, the
   the PW is established.  If it is a different peer, then ST-PE MUST
   send a label release message, with a status code of "Duplicate AII"
   to the PE that originate the LDP label mapping message.

   If the PE has not yet sent a label mapping message for this
   particular PW , then it MUST send the label mapping message to this
   same LDP peer, regardless of what the PW TAII routing lookup result
   is.


7.2.2. Active/Passive T-PE Election Procedure

   When a MS-PW is signaled, Each T-PE might independently start
   signaling the MS-PW, this could result in a different path selected
   for each T-PE PW. To avoid this situation one of the T-PE MUST start
   the PW signaling (active role), while the other waits to receive the
   LDP label mapping before sending the respective PW LDP label mapping
   message. (passive role). The Active T-PE (the ST-PE) and the passive
   T-PE (the TT-PE) MUST be identified before signaling is initiated for
   a given MS-PW.

   The determination of which T-PE assume the active role SHOULD be done
   as follows: the SAII and TAII are compared as unsigned integers, if
   the SAII is bigger then the T-PE assumes the active role.

   The selection process to determine which T-PE assumes the active role
   MAY be superseded by manual provisioning.


7.2.3. Detailed Signaling Procedures

   On receiving a label mapping message, the S-PE MUST inspect the FEC
   TLV. If the receiving node has no local AII matching the TAII for
   that label mapping then the S-PE will check if the FEC is already
   installed for the forward direction:





Martini, et al.                                                [Page 12]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


     - If it is already installed, and the received mapping was received
       from the same LDP peer where the forward LDP label mapping was
       sent, then this label mapping represents signaling in the reverse
       direction for this MS-PW segment.
     - Otherwise this represents signaling in the forward direction.

   For the forward direction:
        -i. Determine the next hop S-PE or T-PE according to the
            procedures above.
       -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE.
            If no tunnel exists to the next hop S-PE or T-PE the S-PE
            MAY attempt to setup a PSN tunnel.
      -iii. Check that a PSN tunnel exists to the previous hop. If no
            tunnel exists to the previous hop S-PE or T-PE the S-PE MAY
            attempt to setup a PSN tunnel.
       -iv. If the S-PE cannot get enough PSN resources to setup the
            segment to the next or previous S-PE or T-PE, a label
            release MUST be returned to the T-PE with a status message
            of "Resources Unavailable".
        -v. If the label mapping message contains a Bandwidth TLV,
            allocate the required resources on the PSN tunnels in the
            forward and reverse directions according to the procedures
            above.
       -vi. Allocate a new PW label for the forward direction.
      -vii. Install the FEC for the forward direction.
     -viii. Send the label mapping message with the new forward label
            and the FEC to the next hop S-PE/T-PE.

   For the reverse direction:
        -i. Install the received FEC for the reverse direction.
       -ii. Determine the next signaling hop by referencing the LDP
            sessions used to setup the LSP in the Forward direction.
      -iii. Allocate a new PW label for the reverse direction.
       -iv. Install the FEC for the reverse direction.
        -v. Send the label mapping message with a new label and the FEC
            to the next hop S-PE/ST-PE.


7.2.4. Support for Explicit PW Path

   The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be
   used to signal an explicit path for a MS-PW. An Explicit PW path may
   be required to provide a simple solution for 1:1 protection with
   diverse primary and backup path or to enable controlled signaling
   (strict or loose) for special PWs. Details of its usage to be
   provided in a future study.





Martini, et al.                                                [Page 13]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


8. Failure Handling Procedures

8.1. PSN Failures

   Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the
   PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD
   follow the procedures defined in Section 8 of [PW-SEG].


8.2. S-PE Reachability Failures

   For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be
   followed. However in general an established MS-PW will not be
   affected by changes in L2 PW reachability information.

   T-PEs that receive a label release message with a status of "AII
   Unreachable" MUST re-attempt to establish the PW immediately. However
   the T-PE MUST throttle its PW setup message retry attempts with an
   exponential backoff in situations where PW setup messages are being
   constantly released.  It is also recommended that a T-PE detecting
   such a situation take action to notify an operator.

   If there is a change in the L2 PW reachability information in the
   forward direction only, the T-PE MAY elect to tear down the MS-PW by
   sending a label withdraw message and re-establish the MS-PW. In the
   same case, an S-PE MAY do the same by sending a label withdraw
   message in the forward direction, and a label release message in the
   opposite direction along the MS-PW.

   A change in L2 reachability information in the reverse direction has
   no effect on an MS-PW.



9. Operations and Maintenance (OAM)

   The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A
   PW switching point TLV is used [PW-SEG] to record the switching
   points that the PW traverses.

   In the case of a MS-PW where the PW Endpoints are identified though
   using a globally unique, FEC 129-based AII addresses, there is no
   PWID defined on a per segment basis. Each individual PW segment is
   identified by the address of adjacent S-PE(s) in conjunction with the
   SAI and TAI. In this case, the following type MUST be used in place
   of type 0x01 in the PW switching point TLV:





Martini, et al.                                                [Page 14]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


   Type      Length    Description
   0x06        10       L2 PW address of PW Switching Point


   The above field MUST be included together with type 0x02 in the TLV
   once per individual PW Switching Point following the same rules and
   procedures as described in [PW-SEG].


10. Security Considerations

   This document specifies only extensions to the protocols already
   defined in [RFC4447], and [PW-SEG]. Each such protocol may have its
   own set of security issues, but those issues are not affected by the
   extensions specified herein. Note that the protocols for dynamically
   distributing PW Layer 2 reachability information may have their own
   security issues, however those protocols specifications are outside
   the scope of this document.


11. IANA Considerations

   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
       0x096E   Bandwidth TLV

11.1. 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 values have been pre-allocated:

   Range/Value     E     Description                       Reference
   ------------- -----   ----------------------            ---------
    0x00000037     0     Bandwidth resources unavailable   RFCxxxx
    0x00000038     0     Resources Unavailable             RFCxxxx
    0x00000039     0     AII Unreachable                   RFCxxxx
    0x0000003A     0     PW Loop Detected                  RFCxxxx










Martini, et al.                                                [Page 15]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


11.2. BGP SAFI

   IANA needs to allocate a new BGP SAFI for "Network Layer Reachability
   Information used for Dynamic Placement of Multi-Segment Pseudiwires"
   from the IANA "Subsequence Address Family Identifiers (SAFI)"
   registry. The following value has been pre-allocated:

   Value    Description                                     Reference
   -----    -----------                                     ---------
   6        Network Layer Reachability Information used [RFCxxxx]
            for Dynamic Placement of Multi-Segment
            Pseudowires


12. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.


13. 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
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.



Martini, et al.                                                [Page 16]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


   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.


14. Normative References

   [PW-SEG] Martini et.al. "Segmented Pseudo Wire",
        draft-ietf-pwe3-segmented-pw-07.txt, IETF Work in Progress,
        February 2008

   [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated
        Services", RFC 2210, September 1997

   [RFC5036] Andersson, Minei, Thomas. "LDP Specification"
        RFC5036, October 2007

   [RFC4447] "Pseudowire Setup and Maintenance Using the Label
        Distribution Protocol (LDP)", Martini L.,et al, RFC 4447,
        June 2005.

   [RFC5003] "Attachment Individual Identifier (AII) Types for
        Aggregation", Metz, et al, RFC5003, September 2007

   [RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP",
        RFC3212, January 2002.



15. Informative References

   [MS-REQ] Martini et al, "Requirements for Multi-Segment Pseudowire
        Emulation Edge-to-Edge (PWE3)",
        draft-ietf-pwe3-ms-pw-requirements-05.txt, Martini, et al.,
        March 2007

   [MS-ARCH] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire
        Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-03.txt,
        June 2007, IETF work in progress

   [RFC2858] Bates, T., Rekhter, Y., Chandra, R. and D. Katz,
        "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

   [L2-SIGNALING] E. Rosen, W. Luo, B. Davie, V. Radoaca,
        "Provisioning, Autodiscovery, and Signaling in L2VPNs",
        draft-ietf-l2vpn-signaling-08.txt May 3, 2006.(work in progress)



Martini, et al.                                                [Page 17]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008


16. Author Information


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


   Matthew Bocci
   Alcatel-Lucent,
   Voyager Place
   Shoppenhangers Road
   Maidenhead
   Berks, UK
   e-mail: matthew.bocci@alcatel-lucent.co.uk


   Florin Balus
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA 94043
   e-mail: florin.balus@alcatel-lucent.com


   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02145
   e-mail: nabil.bitar@verizon.com


   Himanshu Shah
   Ciena Corp
   35 Nagog Park,
   Acton, MA 01720
   e-mail: hshah@ciena.com


   Mustapha Aissaoui
   Alcatel-Lucent
   600 March Road
   Kanata
   ON, Canada
   e-mail: mustapha.aissaoui@alcatel-lucent.com





Martini, et al.                                                [Page 18]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008



   Jason Rusmisel
   Alcatel-Lucent
   600 March Road
   Kanata
   ON, Canada
   e-mail: Jason.rusmisel@alcatel-lucent.com


   Yetik Serbest
   SBC Labs
   9505 Arboretum Blvd.
   Austin, TX 78759
   e-mail: Yetik_serbest@labs.sbc.com


   Andrew G. Malis
   Verizon
   2730 Orchard Parkway
   San Jose, CA, USA 95134
   e-mail: Andy.Malis@tellabs.com


   Chris Metz
   Cisco Systems, Inc.
   3700 Cisco Way
   San Jose, Ca. 95134
   e-mail: chmetz@cisco.com


   David McDysan
   Verizon
   22001 Loudoun County Pkwy
   Ashburn, VA, USA 20147
   e-mail: dave.mcdysan@verizon.com


   Jeff Sugimoto
   Nortel
   3500 Carling Ave.
   Ottawa, Ontario, CANADA
   e-mail: sugimoto@nortel.com









Martini, et al.                                                [Page 19]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008



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


   Mike Loomis
   Nortel
   600, Technology Park Dr
   Billerica, MA, USA
   e-mail: mloomis@nortel.com


   Paul Doolan
   Mangrove Systems
   IO Fairfield Blvd
   Wallingford, CT, USA 06492
   e-mail: pdoolan@mangrovesystems.com


   Ping Pan
   Hammerhead Systems
   640 Clyde Court
   Mountain View, CA, USA 94043
   e-mail: ppan@hammerheadsystems.com


   Prayson Pate
   Overture Networks, Inc.
   507 Airport Blvd, Suite 111
   Morrisville, NC, USA 27560
   e-mail: prayson.pate@overturenetworks.com


   Vasile Radoaca
   Alcatel-Lucent
   Optics Divison, Westford, MA, USA
   email: vasile.radoaca@alcatel-lucent.com


   Yuichiro Wada
   NTT Communications
   3-20-2 Nishi-Shinjuku, Shinjuke-ku
   Tokyo 163-1421, Japan
   e-mail: yuichiro.wada@ntt.com



Martini, et al.                                                [Page 20]

Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-08.txt         July 2008



   Yeongil Seo
   Korea Telecom Corp.
   463-1 Jeonmin-dong, Yusung-gu
   Daejeon, Korea
   e-mail: syi1@kt.co.kr













































Martini, et al.                                                [Page 21]

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/