One document matched: draft-ietf-pwe3-mspw-er-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pwe3-mspw-er-01" ipr="trust200902">
<front>
<title abbrev="MS-PW Explicit Routing">Explicit Path Routing for Dynamic
Multi-Segment Pseudowires</title>
<author fullname="Pranjal Kumar Dutta" initials="P." surname="Dutta">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>701 E Middlefield Road</street>
<city>Mountain View</city>
<region>California</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>pranjal.dutta@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>matthew.bocci@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Luca Martini" initials="L." surname="Martini">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>lmartini@cisco.com</email>
</address>
</author>
<date day="18" month="June" year="2012" />
<abstract>
<t>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
specifies the extensions and procedures required to enable dynamic
MS-PWs to be established along explicit paths.</t>
</abstract>
<note title="Requirements Language">
<t>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<xref
target="RFC2119"></xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Procedures for dynamically establishing multi-segment pseudowires
(MS-PWs), where their paths are automatically determined using a dynamic
routing protocol, are defined in <xref
target="I-D.ietf-pwe3-dynamic-ms-pw"></xref>. For 1:1 protection of
MS-PWs with primary and backup paths, MS-PWs SHOULD be established
through a diverse set of S-PEs (Switching Provider-Edge) nodes to avoid
any single points of failure at PW level. <xref
target="I-D.ietf-pwe3-dynamic-ms-pw"></xref> 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 would 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 network resource management.</t>
<t></t>
</section>
<section title="Terminology">
<t>This document uses the terminology defined in <xref
target="I-D.ietf-pwe3-dynamic-ms-pw"></xref><xref
target="RFC4447">,</xref><xref target="RFC5036"> and</xref>.</t>
<t>The following additional terminology is used:</t>
<t><list style="hanging">
<t hangText="Abstract Node:">A group of nodes (S-PEs) representing
an explicit hop along the path of an MS-PW. An abstract node is
identified by an IPv4, IPv6 or S-PE address.</t>
</list></t>
</section>
<section title="Explicit Path in MS-PW Signaling">
<t>This section describes the LDP (Label Distribution Protocol)
extensions required for signaling explicit paths in dynamic MS-PW set-up
messages.</t>
<section anchor="s-pe-addr" title="S-PE Addressing">
<t>The T-PE MAY elect to select a known explicit path along a set of
S-PEs for a specific PW. This requires that each S-PE be uniquely
addressable in terms of pseudowires. For this purpose, at least one
AII (Attachment Individual Indentifier) address of the format similar
to AII type 2 <xref target="RFC5003"></xref> composed of the Global
ID, and Prefix part, only, MUST be assigned to each S-PE.</t>
<t>If an S-PE is capable of Dynamic MS-PW signaling, but is not
assigned with an S-PE address, then on receiving a Dynamic MS-PW label
mapping message the S-PE MUST return a label release with the
"Resources Unavailable" ( 0x38)" status code.</t>
</section>
<section anchor="er-tlv" title="Explicit Route TLV (ER-TLV)">
<t>The ER-TLV is an object that specifies the path to be taken by the
MS-PW being established. Each hop along the path is represented by an
abstract node, which is a group of one or more S-PEs, identified by an
IPv4, and IPv6 or an S-PE address.</t>
<t>The ER-TLV contains one or more Explicit Route Hop TLVs (ER-Hop
TLVs) defined in <xref target="hop-tlv"></xref>.</t>
<t>The ER-TLV format is defined as follows:</t>
<t><figure title="Explicit Route TLV">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0800 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ............ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U/F
These bits MUST be set to zero and the procedures of [RFC5036]
followed when the TLV is not known to the receiving node.
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.
]]></artwork>
</figure></t>
</section>
<section anchor="hop-tlv" title="Explicit Route Hop TLV (ER-Hop TLV)">
<t>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.</t>
<t>Each ER-Hop TLV has the form:</t>
<t><figure title="ER-Hop TLV">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Content // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U/F
These bits MUST be set to zero and the procedures of [RFC5036]
followed when the TLV is not known to the receiving node.
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.
]]></artwork>
</figure></t>
<t>Details of ER Hop semantics are defined in section 2.4.</t>
</section>
<section title="ER-Hop Semantics">
<t>This section describes the various sementics associated with ER-HOP
TLV.</t>
<section title="ER-Hop 1: IPv4 Prefix">
<t>The abstract node represented by this ER-Hop is the set of nodes,
which have an IPv4 address, which lies within this prefix. Note that
a prefix length of 32 indicates a single IPv4 node.</t>
<t><figure title="ER-Hop with IPv4 Prefix">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0801 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U/F
These bits MUST be set to zero and the procedures of [RFC5036]
followed when the TLV is not known to the receiving node.
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.
]]></artwork>
</figure></t>
</section>
<section title="ER-Hop 2: IPv6 Prefix">
<t>The abstract node represented by this ER-Hop is the set of nodes,
which have an IPv6 address, which lies within this prefix. Note that
a prefix length of 128 indicates a single IPv6 node.<figure>
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| 0x0802 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U/F
These bits MUST be set to zero and the procedures of [RFC5036]
followed when the TLV is not known to the receiving node.
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.
]]></artwork>
</figure></t>
</section>
<section title="ER-Hop 3: L2 PW Address">
<t>The L2 PW Address follows attachment circuit addressing which is
derived from <xref target="RFC5003"></xref> AII type 2, as shown
here:</t>
<t><figure>
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| 0x0802 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (contd.) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U/F
These bits MUST be set to zero and the procedures of [RFC5036]
followed when the TLV is not known to the receiving node.
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].
]]></artwork>
</figure></t>
</section>
</section>
</section>
<section title="Explicit Route TLV Processing">
<t></t>
<section anchor="nexthopselection" title="Next-Hop Selection">
<t>A PW Label Mapping Message containing an explicit route TLV MUST
specify the next hop for a given MS-PW 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
specific and is outside of the scope of this document. The mechanism
used to select a particular path is also outside of the scope of this
document, but each node MUST attempt to determine a loop-free path.
Note that such mechanisms MAY be overridden by local policy.</t>
<t>To determine the next hop for the MS-PW path, a node performs the
following steps. Note that these procedures assume that a valid S-PE
address has been assigned to the node, as per <xref
target="s-pe-addr"></xref>, above.</t>
<t><list style="numbers">
<t>The node receiving the Label Mapping Message must 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 MUST reply with
a Label Release Message with a "Bad Initial ER-Hop Error"
(0x04000004) status code. 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 node should return a "Bad
Explicit Routing TLV Error" (0x04000001) status code in a Label
Release Message sent to upstream node.</t>
<t>If there are no further ER-Hop TLVs following the first ER-Hop
TLV, this indicates the end of the explicit route. The explicit
route TLV MUST be removed from the Label Mapping Message. This
node may or may not be the end of the PW. Processing continues as
per <xref target="AddingERHops"></xref>, where a new explicit
route TLV MAY be added to the Label Mapping Message.</t>
<t>If a second ER-Hop TV does exist, and 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 for the iteration for the next PW segment.</t>
<t>The node determines if it is topologically adjacent to the
abstract node described by the second ER-Hop. That is, it is
directly connected to the next node by a PW control plane
adjacency. 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 as per <xref
target="AddingERHops"></xref>, below.</t>
<t>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:<list style="letters">
<t>If the second ER-Hop is a strict ER-Hop, then there is an
error and the node MUST return a Label Release Message to
upstream node with "Bad Strict Node Error" (0x04000002) status
code.</t>
<t>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 MUST return a Label Release
Message to upstream node with "Bad Loose Node Error"
(0x04000002) status code.</t>
</list></t>
<t>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.</t>
<t>Progress the Label Mapping Message to the next hop.</t>
</list></t>
</section>
<section anchor="AddingERHops"
title="Adding ER Hops to the Explicit Route TLV">
<t>After selecting a next hop, the node may alter the explicit route
in the following ways.</t>
<t>If, as part of executing the algorithm in <xref
target="nexthopselection"></xref>, the explicit route TLV is removed,
the node may add a new explicit route TLV.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="IANA Considerations">
<t>RFC5036 <xref target="RFC5036"></xref> 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.</t>
<t>This draft proposes one new TLV type:</t>
<t><figure>
<artwork><![CDATA[TLV Type Suggested Value
------------------------------------ ---------------
L2 PW Address of Switching point 0x0805
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document introduces no new security considerations over <xref
target="RFC5036"></xref>, <xref target="RFC4447"></xref> and <xref
target="I-D.ietf-pwe3-dynamic-ms-pw"></xref>.</t>
<t></t>
</section>
<section title="Acknowledgements">
<t>The authors gratefully acknowledge the input of Lizhong Jin.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include='reference.RFC.5003'?>
<?rfc include='reference.RFC.4447'?>
<?rfc include='reference.I-D.ietf-pwe3-dynamic-ms-pw'?>
<?rfc include='reference.RFC.5036'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:39:58 |