| 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
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.
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]
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 (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.
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.
This section describes the LDP (Label Distribution Protocol) extensions required for signaling explicit paths in dynamic MS-PW set-up messages.
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:
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.
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:
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.
Details of ER Hop semantics are defined in section 2.3.
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.
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.
The L2 PW Address follows attachment circuit addressing which is derived from [RFC5003] AII type 2, as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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].
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 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:
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.
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
This document introduces no new security considerations over [RFC5036], [RFC4447] and [I-D.ietf-pwe3-dynamic-ms-pw].
The authors gratefully acknowledge the input of Lizhong Jin.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5003] | Metz, C., Martini, L., Balus, F. and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007. |
| [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. |
| [I-D.ietf-pwe3-dynamic-ms-pw] | Martini, L, Bocci, M and F Balus, "Dynamic Placement of Multi Segment Pseudowires", Internet-Draft draft-ietf-pwe3-dynamic-ms-pw-14, July 2011. |
| [RFC5036] | Andersson, L., Minei, I. and B. Thomas, "LDP Specification", RFC 5036, October 2007. |