Explicit Path Routing for Dynamic
Multi-Segment PseudowiresAlcatel-Lucentpranjal.dutta@alcatel-lucent.comAlcatel-Lucentmatthew.bocci@alcatel-lucent.comCisco Systemslmartini@cisco.comDynamic 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.This document uses the terminology defined in , and Procedures for dynamically establishing MS-PWs through automatically
selected paths are defined in . 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. 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 required for setting up of
dynamic MS-PWs through explicit paths. Procedures for dynamically
establishing MS-PWs through automatically selected paths are defined in
. 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. 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 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: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: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.The L2 PW Address follows attachment circuit addressing which is
derived from AII type 2, as shown
here: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: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.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.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.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.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.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: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.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.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.Progress the Label Mapping Message to the next hop.After selecting a next hop, the node may alter the explicit route
in the following ways.If, as part of executing the algorithm in , 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 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 0x0805This document introduces no new security considerations over , and .The authors gratefully acknowledge the input of Lizhong Jin.