Explicit Path Routing for Dynamic Multi-Segment Pseudowires
draft-ietf-pwe3-mspw-er-00

Network Working Group                                           P. Dutta
Internet-Draft                                                  M. Bocci
Intended status: Standards Track                          Alcatel-Lucent
Expires: March 25, 2012                                       L. Martini
                                                           Cisco Systems
                                                      September 22, 2011

      Explicit Path Routing for Dynamic Multi-Segment Pseudowires
                       draft-ietf-pwe3-mspw-er-00

Abstract

   Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit
   path may be required to provide a simple solution for 1:1 protection
   with diverse primary and backup MS-PWs for a service, or to enable
   controlled signaling (strict or loose) for special MS-PWs.  This
   document describes the extensions and procedures necessary for
   setting up of dynamic MS-PWs through explicit path routing.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in[RFC2119].

   This document uses the terminology defined in
   [I-D.ietf-pwe3-dynamic-ms-pw], [RFC4447]and [RFC5036]

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 25, 2012.

Copyright Notice

Dutta, et al.            Expires March 25, 2012                 [Page 1]
Internet-Draft           MS-PW Explicit Routing           September 2011

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Explicit Path in MS-PW Signaling . . . . . . . . . . . . . . .  3
     2.1.  Explicit Route TLV (ER-TLV)  . . . . . . . . . . . . . . .  3
     2.2.  Explicit Route Hop TLV (ER-Hop TLV)  . . . . . . . . . . .  4
     2.3.  ER-Hop Semantics . . . . . . . . . . . . . . . . . . . . .  6
       2.3.1.  ER-Hop 1: IPv4 Prefix  . . . . . . . . . . . . . . . .  6
       2.3.2.  ER-Hop 2: IPv6 Prefix  . . . . . . . . . . . . . . . .  6
       2.3.3.  ER-Hop 3: L2 PW Address  . . . . . . . . . . . . . . .  7
   3.  Explicit Route TLV Processing  . . . . . . . . . . . . . . . .  8
     3.1.  Next-Hop Selection . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Adding ER Hops to the Explicit Route TLV . . . . . . . . . 10
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Acknoledgements  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

Dutta, et al.            Expires March 25, 2012                 [Page 2]
Internet-Draft           MS-PW Explicit Routing           September 2011

1.  Introduction

   Procedures for dynamically establishing MS-PWs through automatically
   selected paths are defined in [I-D.ietf-pwe3-dynamic-ms-pw].  For 1:1
   protection of MS-PWs with primary and backup paths it is required to
   set-up MS-PWs through a diverse set of S-PEs (Switching Provider-Edge
   Devices) to remove any single points of failure at PW level.
   [I-D.ietf-pwe3-dynamic-ms-pw] allows this through BGP based
   mechanisms.  This draft proposes an additional mechanism that allows
   the ST-PE (Source Terminating PEs) to explicitly choose the path that
   a PW will take through the intervening S-PEs.  Explicit path routing
   of dynamic MS-PWs may also be required for controlled set-up of
   dynamic MS-PWs and efficient network resource management.  This
   documents defined extensions and procedures to
   [I-D.ietf-pwe3-dynamic-ms-pw] required for setting up of dynamic MS-
   PWs through explicit paths.  Procedures for dynamically establishing
   MS-PWs through automatically selected paths are defined in
   [I-D.ietf-pwe3-dynamic-ms-pw].  For 1:1 protection of MS-PWs with
   primary and backup paths it is required to set-up MS-PWs through a
   diverse set of S-PEs to remove any single points of failure at PW
   level.  [I-D.ietf-pwe3-dynamic-ms-pw] allows this through BGP based
   mechanisms.

   This draft proposes an additional mechanism that allows the ST-PE to
   explicitly choose the path that a PW will take through the
   intervening S-PEs.  Explicit path routing of dynamic MS-PWs may also
   be required for controlled set-up of dynamic MS-PWs and efficient
   network resource management.  This documents defined extensions and
   procedures to [I-D.ietf-pwe3-dynamic-ms-pw] required for setting up
   of dynamic MS-PWs through explicit paths.

2.  Explicit Path in MS-PW Signaling

   This section describes the LDP (Label Distribution Protocol)
   extensions required for signaling explicit paths in dynamic MS-PW
   set-up messages.

2.1.  Explicit Route TLV (ER-TLV)

   The ER-TLV is an object that specifies the path to be taken by the
   MS-PW being established.  It is composed of one or more Explicit
   Route Hop TLVs (ER-Hop TLVs) defined in Section 2.2.  Note that
   Explicit Route TLV definition is very generic and may be also used
   outside of MS-PW applications.  Such applications are out of scope of
   this document.

   The ER-TLV format is defined as follows:

Dutta, et al.            Expires March 25, 2012                 [Page 3]
Internet-Draft           MS-PW Explicit Routing           September 2011

       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|         Type = 0x0800     |      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          ER-Hop TLV 1                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          ER-Hop TLV 2                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          ............                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          ER-Hop TLV n                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type
            A fourteen-bit field carrying the value of the ER-TLV
            Type = 0x0800.

      Length
            Specifies the length of the value field in bytes.

      ER-Hop TLVs
            One or more ER-Hop TLVs defined in Section 3.2.

                            Explicit Route TLV

2.2.  Explicit Route Hop TLV (ER-Hop TLV)

   The contents of an ER-TLV are a series of variable length ER-Hop
   TLVs.  Each hop contains the identification of an "Abstract Node"
   that represents the hop to be traversed.

   Each ER-Hop TLV has the form:

Dutta, et al.            Expires March 25, 2012                 [Page 4]
Internet-Draft           MS-PW Explicit Routing           September 2011

     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|                 Type      |      Length                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |L|                                  Content //                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    ER-Hop Type

          A fourteen-bit field carrying the type of the ER-Hop contents.
          Currently defined values are:

          Value  Type
          ------ ------------------------
          0x0801 IPv4 prefix
          0x0802 IPv6 prefix
          0x0805 L2 PW address of PW Switching Point

    Length
          Specifies the length of the value field in bytes.

    L bit
          The L bit in the ER-Hop is a one-bit attribute.  If the L bit
          is set, then the value of the attribute is "loose." Otherwise,
          the value of the attribute is "strict."  For brevity, we say
          that if the value of the ER-Hop attribute is loose then it is
          a "loose ER-Hop."  Otherwise, it's a "strict ER-Hop." Further,
          we say that the abstract node of a strict or loose ER-Hop is a
          strict or a loose node, respectively.  Loose and strict nodes
          are always interpreted relative to their prior abstract nodes.
          The path between a strict node and its prior node MUST include
          only network nodes from the strict node and its prior abstract
          node.

          The path between a loose node and its prior node MAY include
          other network nodes, which are not part of the strict node or
          its prior abstract node.

    Contents
          A variable length field containing a node or abstract node
          which is one of the consecutive nodes that make up the
          explicitly routed PW.

                                ER-Hop TLV

   Details of ER Hop semantics are defined in section 2.3.

Dutta, et al.            Expires March 25, 2012                 [Page 5]
Internet-Draft           MS-PW Explicit Routing           September 2011

2.3.  ER-Hop Semantics

2.3.1.  ER-Hop 1: IPv4 Prefix

   The abstract node represented by this ER-Hop is the set of nodes,
   which have an IP address, which lies within this prefix.  Note that a
   prefix length of 32 indicates a single IPv4 node.

      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|         Type = 0x0801     |      Length = 8               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|      Reserved                               |    PreLen     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    IPv4 Address (4 bytes)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type
           A fourteen-bit field carrying the value of the ER-Hop 1, IPv4
           Address, Type = 0x0801

     Length
           Specifies the length of the value field in bytes = 8.

     L Bit
           Set to indicate Loose hop.
           Cleared to indicate a strict hop.

     Reserved
           Zero on transmission.  Ignored on receipt.

     PreLen
           Prefix Length 1-32

     IP Address
           A four-byte field indicating the IP Address.

                          ER-Hop with IPv4 Prefix

2.3.2.  ER-Hop 2: IPv6 Prefix

Dutta, et al.            Expires March 25, 2012                 [Page 6]
Internet-Draft           MS-PW Explicit Routing           September 2011

      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|          0x0802           |      Length = 20              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|             Reserved                        |    PreLen     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  IPV6 address                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  IPV6 address (continued)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  IPV6 address (continued)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  IPV6 address (continued)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type
           A fourteen-bit field carrying the value of the ER-Hop 2, IPv6
           Address, Type = 0x0802

     Length
           Specifies the length of the value field in bytes = 20.

     L Bit
           Set to indicate Loose hop.
           Cleared to indicate a strict hop.

     Reserved
           Zero on transmission.  Ignored on receipt.

     PreLen
           Prefix Length 1-128

     IPv6 address
           A 128-bit unicast host addresses.

2.3.3.  ER-Hop 3: L2 PW Address

   The L2 PW Address follows attachment circuit addressing which is
   derived from [RFC5003] AII type 2, as shown here:

Dutta, et al.            Expires March 25, 2012                 [Page 7]
Internet-Draft           MS-PW Explicit Routing           September 2011

     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|          0x0802           |      Length = 18              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |L|             Reserved                        |    PreLen     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  AII Type=02  |    Length     |        Global ID              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Global ID (contd.)      |        Prefix                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Prefix (contd.)         |        AC ID                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      AC ID                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type
          A fourteen-bit field carrying the value of the ER-Hop 3, L2 PW
          Address, Type = 0x0805

    Length
          Specifies the length of the value field in bytes = 18.

    L Bit
          Set to indicate Loose hop.
          Cleared to indicate a strict hop.

    Reserved
          Zero on transmission.  Ignored on receipt.

    PreLen
          Prefix Length 1-96

    L2 PW Address
          An AII Address as defined in [RFC5003].

3.  Explicit Route TLV Processing

3.1.  Next-Hop Selection

   A PW Label Mapping Message containing an explicit route TLV must
   determine the next hop for this path.  Selection of this next hop may
   involve a selection from a set of possible alternatives.  The
   mechanism for making a selection from this set is implementation
   dependent and is outside of the scope of this specification.
   Selection of particular paths is also outside of the scope of this

Dutta, et al.            Expires March 25, 2012                 [Page 8]
Internet-Draft           MS-PW Explicit Routing           September 2011

   specification, but it is assumed that each node will make a best
   effort attempt to determine a loop-free path.  Note that such best
   efforts may be overridden by local policy.

   To determine the next hop for the path, a node performs the following
   steps:

   1.  If a node receiving the Label Mapping Message including an ER-
       Hop Type that is not supported MUST not progress the Label
       Mapping message to downstream LSR and MUST send back an "Unknown
       TLV" Notification.

   2.  The node receiving the Label Mapping Message must first evaluate
       the first ER-Hop.  If the L bit is not set in the first ER-Hop
       and if the node is not part of the abstract node described by the
       first ER-Hop, it has received the message in error, and should
       return a "Bad Initial ER-Hop Error" status.  If the L bit is set
       and the local node is not part of the abstract node described by
       the first ER-Hop, the node selects a next hop that is along the
       path to the abstract node described by the first ER-Hop.  If
       there is no first ER-Hop, the message is also in error and the
       system should return a "Bad Explicit Routing TLV Error" status
       using a Notification Message sent upstream.

   3.  If there is no second ER-Hop, this indicates the end of the
       explicit route.  The explicit route TLV should be removed from
       the Label Mapping Message.  This node may or may not be the end
       of the PW.  Processing continues with section 3.2, where a new
       explicit route TLV may be added to the Label Mapping Message.

   4.  If the node is also a part of the abstract node described by the
       second ER-Hop, then the node deletes the first ER-Hop and
       continues processing with step 2, above.  Note that this makes
       the second ER-Hop into the first ER-Hop of the next iteration.

   5.  The node determines if it is topologically adjacent to the
       abstract node described by the second ER-Hop.  If so, the node
       selects a particular next hop which is a member of the abstract
       node.  The node then deletes the first ER-Hop and continues
       processing with section 3.2.

   6.  Next, the node selects a next hop within the abstract node of the
       first ER-Hop that is along the path to the abstract node of the
       second ER-Hop.  If no such path exists then there are two cases:

       A.  If the second ER-Hop is a strict ER-Hop, then there is an
           error and the node should return a "Bad Strict Node Error"
           status.

Dutta, et al.            Expires March 25, 2012                 [Page 9]
Internet-Draft           MS-PW Explicit Routing           September 2011

       B.  Otherwise, if the second ER-Hop is a loose ER-Hop, then the
           node selects any next hop that is along the path to the next
           abstract node.  If no path exists within the MPLS domain,
           then there is an error, and the node should return a "Bad
           Loose Node Error" status.

   7.  Finally, the node replaces the first ER-Hop with any ER-Hop that
       denotes an abstract node containing the next hop.  This is
       necessary so that when the explicit route is received by the next
       hop, it will be accepted.

   8.  Progress the Label Mapping Message to the next hop.

3.2.  Adding ER Hops to the Explicit Route TLV

   After selecting a next hop, the node may alter the explicit route in
   the following ways.

   If, as part of executing the algorithm in Section 3.1, the explicit
   route TLV is removed, the node may add a new explicit route TLV.

   Otherwise, if the node is a member of the abstract node for the first
   ER-Hop, then a series of ER-Hops may be inserted before the First ER-
   Hop or may replace the first ER-Hop.  Each ER-Hop in this series must
   denote an abstract node that is a subset of the current abstract
   node.

   Alternately, if the first ER-Hop is a loose ER-Hop, an arbitrary
   series of ER-Hops may be inserted prior to the first ER-Hop.

4.  IANA Considerations

   RFC5036 [RFC5036] defines the LDP TLV name space which is maintained
   by IANA as "LDP TLV Registry".  TLV types for the Explicit Route TLV,
   IPv4 Prefix ER-Hop TLV, and the IPv6 Prefix ER-Hop TLV are already
   defined in the LDP TLV Registry.

   This draft proposes one new TLV type:t.

   TLV Type (Suggested)

   -------------------------------------- ----------

   L2 PW Address of Switching Point 0x0805

Dutta, et al.            Expires March 25, 2012                [Page 10]
Internet-Draft           MS-PW Explicit Routing           September 2011

5.  Security Considerations

   This document introduces no new security considerations over
   [RFC5036], [RFC4447] and [I-D.ietf-pwe3-dynamic-ms-pw].

6.  Acknoledgements

   The authors gratefully acknowledge the input of Lizhong Jin.

7.  Normative References

   [I-D.ietf-pwe3-dynamic-ms-pw]
              Martini, L., Bocci, M., and F. Balus, "Dynamic Placement
              of Multi Segment Pseudowires",
              draft-ietf-pwe3-dynamic-ms-pw-14 (work in progress),
              July 2011.

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

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC5003]  Metz, C., Martini, L., Balus, F., and J. Sugimoto,
              "Attachment Individual Identifier (AII) Types for
              Aggregation", RFC 5003, September 2007.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

Authors' Addresses

   Pranjal Dutta
   Alcatel-Lucent

   Email: pranjal.dutta@alcatel-lucent.com

Dutta, et al.            Expires March 25, 2012                [Page 11]
Internet-Draft           MS-PW Explicit Routing           September 2011

   Matthew Bocci
   Alcatel-Lucent

   Email: matthew.bocci@alcatel-lucent.com

   Luca Martini
   Cisco Systems

   Email: lmartini@cisco.com

Dutta, et al.            Expires March 25, 2012                [Page 12]