Internet DRAFT - draft-shah-bocci-pwe3-ms-pw-signaling
draft-shah-bocci-pwe3-ms-pw-signaling
PWE3 Working Group Himanshu Shah
Internet Draft Ciena Corp
Matthew Bocci
Mustapha Aissaoui
Jason Rusmisel
Alcatel
Yetik Serbest
SBC
Nabil Bitar
Verizon
Expires: January 2006 July 2005
Multi-Segment Pseudo Wire Signaling
draft-shah-bocci-pwe3-ms-pw-signaling-01.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/ietf/1id-abstracts.txt
Shah et al Expires January 2006 [Page 1]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
The pseudowire switching [6] draft describes how a Pseudowire can
span across multiple PSN domains. This multi-segment PW (MS-PW)
threads through one or more PEs that are not the endpoints of the PW
and are called switching PE (S-PE). The switching PE at each hop is
configured a-priori with two single hops PW information that enables
it to conduct splicing between the two. The configuration of such
information at each S-PE for possibly thousands of MS-PWs is
cumbersome. We describe a mechanism whereby a S-PE can identify and
process the PW control signaling with the information present in the
signaling message in a manner that eliminates the requirement to
configure PW splicing information. In this mechanism source PE
inserts information about the destination PE and the PW endpoint that
is recognized by the receiving PE to identify his role as a switching
PE and engage in propagating the PW signal towards the destination
PE.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 [1].
Table of Contents
1. Introduction...................................................3
1.1. Scope.....................................................3
1.2. Architectural Model.......................................4
1.3. Overview of the proposed solution.........................7
2. Terminology....................................................9
3. Applicability..................................................9
4. Multi-segment Pseudo Wire Configuration........................9
5. MS-PW Information in the Label Mapping Message................11
Shah et al Expires January 2006 [Page 2]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
6. Next Hop Selection............................................12
7. PW Loop Detection.............................................13
8. Explicit Route support........................................13
9. Signaling procedures..........................................13
9.1. MS-PW signaling in the Forward Direction.................14
9.1.1. The role of SU-PE...................................14
9.1.2. The Role of S-PE....................................15
9.1.3. The Role of TU-PE...................................17
9.2. MS-PW Signaling in the Reverse Direction.................18
9.2.1. The Role of the TU-PE...............................18
9.2.2. The Role of the S-PE................................19
9.2.3. The Role of SU-PE...................................20
9.3. Signaling role...........................................21
10. PW status processing.........................................21
11. Peer PW ID...................................................22
12. Mechanisms for using Generalized ID FEC......................23
13. Resiliency...................................................23
14. Scalability..................................................24
15. Aspects for Further Study....................................24
16. Security Considerations......................................25
17. Acknowledgments..............................................25
18. References...................................................25
18.1. Normative References....................................25
18.2. Informative References..................................25
Author's Addresses...............................................26
Intellectual Property Statement..................................27
Disclaimer of Validity...........................................27
Copyright Statement..............................................27
Acknowledgment...................................................27
1. Introduction
1.1. Scope
The multi-segment pseudo-wire requirements draft [5] describes a
multi-segment pseudo wire as a concatenation of multiple single
segment pseudo wires.
[6] describes a solution in which, at each hop, two pseudo wires are
configured; one-half of the pseudo wire to the preceding hop and
other half of the pseudo wire to the succeeding hop. When a switching
Shah et al Expires January 2006 [Page 3]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
PE receives PW signal on any half of the pseudo wire, it triggers a
PW signal on the other half of pseudo wire in order for the signaling
to thread through each hop all the way to the destination. The
requirement of pre-configuring the segments of a pseudo wire at each
hop presents administrative overhead which increases as the number of
multi-segment pseudo wires increase. In addition, it limits the
flexibility of ultimate PE to dynamically re-route a multi-segment
pseudo wire through a different set of one or more switching PEs.
The goal of the solution proposed in this document is to:
o Eliminate the need to pre-configure pseudo wire segments at
switching PEs.
o Provide QOS information to each switching PE in order for them to
intelligently manage the network resources.
o Build on, as far as possible, the existing pseudo wire control
protocol methodologies.
o Provide mechanisms to build a backup pseudo wire.
The following sections describe the solution with definition of
additional information elements, the role of the source PE, switching
PE and target PE in the creation, maintenance and termination of the
multi-segment pseudo wire. The document does not describe the
permutations and combinations of different control planes and PSN
technologies. This subject is covered in detail in [6]. Among the
several cases described in [6], the only case undertaken in this
document is the multi-segment PW consisting of a concatenation of
single-segment pseudo wires that are signaled dynamically. The
signaling protocol proposed is based on the PW control protocol [3]
using Targeted LDP in Downstream Unsolicited mode.
The proposal in this document is intended as a logical progression
from the existing signaling standards for single-segment PWs. As
such, the basic signaling is kept simple.
1.2. Architectural Model
Shah et al Expires January 2006 [Page 4]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
The following two figures describe the reference models, which are
derived from [5] to support PW emulated services.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Attachment Circuit (AC) Attachment Circuit (AC)
native service native service
Figure 1: PWE3 Reference Configuration
Shah et al Expires January 2006 [Page 5]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
Native |<-----------Pseudo Wire----------->| Native
Layer2 | | Layer2
Service | |<-PSN1-->| |<--PSN2->| | Service
(AC) V V V V V V (AC)
| +----+ +-----+ +----+ |
+----+ | | PE1|=========| PE2 |=========| PE3| | +----+
| |----------|........PW1.........|...PW3........|----------| |
| CE1| | | | | | | | | |CE2 |
| |----------|........PW2.........|...PW4........|----------| |
+----+ | | |=========| |=========| | | +----+
^ +----+ +-----+ +----+ | ^
| Provider Edge 1 ^ Provider Edge 3 |
| | |
| | |
| PW switching point |
| |
| |
|<------------------- Emulated Service ------------------>|
Figure 2: PW switching Reference Model
Figure 2 extends the single segment PW architecture to show a
generalized multi-segmented PW case. PE1 and PE3 provide PWE3 to CE1
and CE2. These PEs reside in different PSNs. A PSN tunnel extends
from PE1 to PE2 across PSN1, and a second PSN tunnel extends from PE2
to PE3 across PSN2. PWs are used to connect the Attachment circuits
(ACs) attached to PE1 to the corresponding ACs attached to PE3. Each
PW on the tunnel across PSN1 is stitched to a PW in the tunnel across
PSN2 at PE2 to complete the multi-segment PW (MS-PW) between PE1 and
PE3. PE2 is therefore the PW switching point and will be referred to
as the PW switching provider edge (S-PE). PW1 and PW3 are segments of
the same MS-PW while PW2 and PW4 are segments of another pseudo wire.
PW segments of the same MS-PW (e.g., PW1 and PW3) MUST be of the same
PW type. Note that although Figure 2 only shows a single S-PE, a PW
may transit more than one S-PE along its path.
Shah et al Expires January 2006 [Page 6]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
|<--------------Pseudo Wire----------->|
| Provider Provider |
AC | |<----1---->| |<----2--->| | AC
| V V V V V V |
| +----+ +-----+ +----+ +----+ |
+----+ | | |=====| |=====| |=====| | | +----+
| |-------|.....PW1..........PW2.........PW3.....|-------| |
| CE1| | | | | | | | | | | |CE2 |
+----+ | | |=====| |=====| |=====| | | +----+
^ +----+ +-----+ +----+ +----+ ^
| PE1 PE2 PE3 PE4 |
| ^ ^ |
| | | |
| PW switching points |
| |
| |
|<------------------- Emulated Service --------------->|
Figure 3: PW Switching Interprovider Reference Model
Figure 3 shows the inter-provider reference model [5]. In this case,
the two PSNs are administered by provider 1 and provider 2
respectively. PE2 and PE3 represent both ASBRs for those providers,
and S-PEs for the inter-provider PWs. An MPLS interface is assumed
between PE2 and PE3, which are interconnected using an inter-provider
PSN tunnel.
1.3. Overview of the proposed solution
This document proposes signaling methodologies for U-PEs and S-PEs
such that a multi-segmented PW can be extended across multiple PSN
domains without having to configure the intermediate PE hops. The key
points of the procedure are briefly described below. Detailed
procedures are provided in subsequent sections.
o Both U-PEs are locally configured with PW specific information
relevant to the PW ID FEC.
o Each U-PE determines its role with respect to MS-PW signaling,
i.e., active or passive, based on local configuration of the MS-
PW. If the local configuration does not specify it, a U-PE
compares its IP address with that of its peer U-PE. The higher
address value takes an active role and initiates the MS-PW
signaling, while the lower address value takes a passive role. The
passive U-PE waits for the MS-PW signaling message to arrive from
its peer.
Shah et al Expires January 2006 [Page 7]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o The active U-PE (known as the source U-PE or SU-PE) prepares a MS-
PW TLV and sends the MS-PW Label Mapping message to one or more
next hop T-LDP peers. Section 6. describes how the next hop can be
chosen. However, details of PW routing are outside the scope of
this draft.
o The switching PE (S-PE) recognizes the MS-PW label-mapping message
based on the PW type, processes it, adds its own label, and then
forwards it to a subset of T-LDP peers, as described above. Note
that the S-PE may receive more than one MS-PW label-mapping
message for a given MS-PW FEC. The following sections describe how
this case is handled.
o One or more copies of MS-PW label-mapping message may arrive
through one or more paths at the last PW segment where the Target
U-PE (TU-PE) resides. All the S-PEs on the target segment
recognize the TU-PE to be their T-LDP peer, and thus only send the
MS-PW Label Mapping message to that TU-PE.
o The TU-PE may receive multiple MS-PW Label Mapping messages for
the same MS-PW FEC from the set of previous hop S-PEs. It selects
one as its primary path from a penultimate hop S-PE, processes the
message, and advertises the Label Mapping in the reverse
direction. If the methods proposed in Section 6. are not used, a
label release is issued for each of the received Label Mappings
that were not selected. This triggers a tear down of the dangling
PWs in the reverse direction that were not selected for return
path. Note however that the TU-PE can select a backup path at the
same time of the primary path. In this case, it issues a Label
Mapping message on both the primary and backup paths. All other
labels are released.
o The selected penultimate hop S-PE finds the MS-PW record created
during the forward path processing and selects the previous hop
for the MS-PW in the reverse direction.
o The MS-PW signaling in the reverse direction continues on to pin
down the bidirectional PW at each segment. Only one copy of MS-PW
Label Mapping message is expected to arrive at SU-PE, except when
the TU-PE attempts to establish a backup MS-PW at the same time.
The procedures in this case are explained later in this document.
The following sections discuss the detailed signaling procedures, TLV
definitions, QOS characteristics, resiliency, OAM handling, etc.
Shah et al Expires January 2006 [Page 8]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
2. Terminology
[5] provides terminology for multi-segment pseudo wires.
This document defines the following additional terms:
o Source Ultimate PE (SU-PE). An Ultimate PE (U-PE), which assumes
the active signaling role and initiates the signaling for multi-
segment PW.
o Target Ultimate PE (TU-PE). An Ultimate PE (U-PE) that assumes the
passive signaling role. It waits and responds to the multi-segment
PW signaling message in the reverse direction.
o Forward Direction: SU-PE to TU-PE.
o Reverse Direction: TU-PE to SU-PE
o Forwarding Direction: Direction of data plane traffic flow
3. Applicability
Content for this section will be added in a future revision of this
document.
4. Multi-segment Pseudo Wire Configuration
As per the PW ID FEC model, only the U-PEs are required to be
configured for the MS-PW. There is no configuration required at the
S-PEs for the MS-PW Signaling.
The information configured at the SU-PE is as follows:
o PW type - This is a new PW type called "Multi-Segment PW" type to
be assigned by IANA.
Shah et al Expires January 2006 [Page 9]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o TU-PE's IP address. The IP address of the remote PE is always
configured for each PW. However, when the PW type is MS-PW, SU-PE
recognizes the difference in modus operandi that is required.
o Active/Passive Signaling Role - This optional configuration
selects signaling role to be of type Active since this is the
Source U-PE. Note that when this configuration is used, a
corresponding configuration at the TU-PE is necessary.
o QOS requirements for forward and reverse directions, such as PW
traffic parameters - the value used by all PEs. The manner in
which these traffic parameters are used to reserve resources and
apply admission control at PEs in the forward and/or reverse
directions (if applicable) is determined by local policy. The QOS
related configuration is OPTIONAL.
o MS-PW type for the U-PE - the value used only by U-PEs and not S-
PEs. The values correspond to the types as those defined for SH-PW
[4].
o MS-PW ID for the U-PE - the value used only by U-PEs and not S-
PEs. The value has the same meaning as that defined SH-PW [3]. The
MS-PW ID is signaled in the MS-PW TLV and is different from the PW
ID in the PW ID FEC. This latter is renamed "Peer PW ID" and its
use is described in Section 11.
o TTL - the value used by all S-PEs. This is OPTIONAL.
o Creation of disjoint path backup PW for this MS-PW FEC.
The information configured at the TU-PE is a somewhat smaller set as
this PE plays a passive role in MS-PW signaling.
o SU-PE's IP address - used to verify and accept MS-PW signal
o Active/Passive Signaling Role - This optional configuration
selects signaling role to be of type Passive since this is the
Target U-PE. Note that when this configuration is used, a
corresponding configuration at the SU-PE is necessary.
o QOS requirements for forward and reverse directions, such as PW
traffic parameters - the value used by all PEs. This is OPTIONAL.
Note that the QOS requirements contained in the Label Mapping
message in the forwarding direction takes precedence over the
configured information on the TU-PE.
Shah et al Expires January 2006 [Page 10]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o MS-PW type for the U-PE - this must be the same value as the one
configured at the SU-PE.
o MS-PW ID for the U-PE - this must be the same value as the one
configured at the SU-PE.
o TTL - the value used by all S-PEs. This is OPTIONAL.
5. MS-PW Information in the Label Mapping Message
The following information is needed in the MS-PW signaling for PW ID
FEC 128. These additional fields are inside the MS-PW TLV. The
information for generalized ID FEC (129) is described later.
o Direction. Set as either forward or reverse
o SU-PE's IP Address
o TU-PE's IP Address
o PW role - active or passive. This is OPTIONAL.
o MS-PW ID as configured at SU-PE and TU-PE. This PW ID has
relevance only at U-PEs.
o MS-PW Type as configured at SU-PE and TU-PE. This PW type has
relevance only at U-PEs.
o Hop count. Incremented by each S-PE
o TTL. Set by SU-PE and decremented by each S-PE. When TTL becomes
zero, a Label Release is triggered in the reverse direction
o PW relative forwarding priority: this is set to zero by the SU-PE
in the forward label mapping message. It is set to a value higher
than zero by the TU-PE in the one or many reverse label mapping
messages. If more than one PW is established, e.g. primary and
backup, the TU-PE uses this field to indicate to SU-PE the
priority order in which it intends to use the primary and backup
PW paths to forward traffic. When SU-PE receives the labels for
the successful paths, it will start forwarding traffic using the
label of the highest priority PW. It will also expect to receive
traffic over the label of that same PW.
Shah et al Expires January 2006 [Page 11]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o Path TLV. LDP [RFC 3036] defines the use of a Path TLV to collect
the LSR hops during LDP signaling propagation. [6] describes the
use of a Path TLV in the MS-PW architecture to build path trace
through S-PEs. The MS-PW signaling leverages this construct to
ensure that the backup path is disjoint from the primary path.
o Requested QOS TLV [7]. This is set by SU-PE. Each S-PE uses this
to check availability of resources on the transport tunnel. This
is OPTIONAL.
o Available QOS TLV. This is set by SU-PE when signaling MS-PW and
modified by each S-PE upward or downward. The TU-PE and S-PEs may
use this as path selection criteria for MS-PW in the respective
direction. The SU-PE initializes the available QOS TLV same as
requested QOS TLV. This is optional and must be absent if
Requested QOS TLV is not present
6. Next Hop Selection
This scheme can make use of one or more of the following mechanisms
to choose the next hop. Details of these mechanisms and PW routing in
general, is outside the scope of this draft. This list is not
exclusive.
o Each PE may intelligently choose the set of next hop PEs based on
I-BGP / E-BGP queries. For example, in the inter-provider case
shown in Figure 3, PE2 in provider 1 is an ASBR for AS1 and PE3 in
provider 2 is an ASBR for AS2. They both have E-BGP session
between each other and hence know about each other. PE2 and PE3
would also have T-LDP sessions between each other. Once the MS-PW
label mapping message reaches PE3 in AS2, it would use IGP/BGP to
reach the S-PE which is connected to another AS.
o Each S-PE checks the QOS and load capacity in reverse direction,
enabling this S-PE to determine if it is a suitable S-PE for the
establishment of both directions of the PW.
o If the S-PE is an ASBR, including the AS number in the MS-PW
signaling message and preventing propagation to an AS that it has
already traversed.
Shah et al Expires January 2006 [Page 12]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o By configuring a "gateway" capability on each PE. In general,
there are many PEs on a PSN. Some may be U-PEs, some are S-PEs and
some are both. For S-PEs, some may be inter-area boundary nodes,
some may be inter-routing domain boundary nodes and some may be
inter-AS boundary nodes. Of these, some may be PW switching
capable while others are not. A service provider can select a
small set of PEs that are gateways and only those would process
the MS-PE signals. E-BGP, I-BGP does not use this attribute as a
criterion for the best next hop selection. Adding this additional
check further narrows the breadth of MS-PW signaling scope.
The use of these methods will minimize signaling overhead.
7. PW Loop Detection
In order to provide a loop detection mechanism, a S-PE MAY support
the OPTIONAL PW switching point TLV and associated procedures as
described in [6].
8. Explicit Route support
In some situations it may be required that the decision on which next
hop the S-PE should choose must be given to the source U-PE. For
example, there may be administrative reasons why PWs must be
constrained to particular route. Also, the SU-PE may have access to a
traffic-engineering database for its local domain and may wish to
determine the preferred exit point from its domain at a given time.
Mechanisms for PW routing are outside the scope of this draft.
9. Signaling procedures
The signaling procedures are described based on the direction in
which the MS-PW signaling message is traveling and how each PE
processes a message. The forward direction is considered to be from
the preceding to the succeeding side with respect to the SU-PE i.e.
from SU-PE to TU-PE.
The first step in the signaling procedure is the determination of the
role of the U-PE. When a PW is configured on a PE, it first
determines if the PW is of type MS-PW. Note that a MS-PW does not
necessarily mean that it has to pass through multiple PW segments. It
is entirely possible that TU-PE may be T-LDP peer of the SU-PE as it
resides on the same PSN domain. However, if the U-PE is not T-LDP
peer and the PW type is MS-PW, then each U-PE engages in determining
Shah et al Expires January 2006 [Page 13]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
its role in MS-PW signaling by checking the local configuration. If
such information is not configured, each U-PE compares his own IP
address with its peer's IP address. If the value is higher, U-PE
assumes an active role and initiates the MS-PW signaling message.
This will be a Label Mapping message. This U-PE is referred to as
Source U-PE, or SU-PE. The passive U-PE awaits this MS-PW signaling
message to arrive and is referred to as the TU-PE.
9.1. MS-PW signaling in the Forward Direction
9.1.1. The role of SU-PE
The SU-PE initiates the MS-PW signal in the forwarding direction.
The SU-PE dispatches PW signaling as described in [3]. The PW ID,
also known as the Peer PW ID, is set as described in Section 11. The
PW-type is set to the new "Multi-Segment PW" type. The MS-PW TLV is
added in the optional TLV field of the Label Mapping message and is
initialized as follows.
o Direction field is set to Forward.
o MS PW ID is set to the value configured locally by the user.
o MS-PW TYPE is set to PWE3 service type as defined in [4] and is
based on the type of Attachment Circuit present at the U-PEs. This
value is configured by the user.
o SU-PE IP address is configured as the IP address of the LDP
entity.
o TU-PE IP address is configured as IP of address of the TU-PEÆs
LDP entity.
o TTL is configured by the user. The TTL field represents the
maximum number of hops that MS-PW signal is willing to pass
through.
o Hop count is set to zero.
Shah et al Expires January 2006 [Page 14]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o The optional QOS parameters are set in the QOS TLV to indicate
to each PE the QOS expectations for the reverse direction
traffic. Optionally, an additional QOS TLV can also be
dispatched marked as available QOS TLV. Each receiving PE can
then modify this TLV upward or downward fashion based on what
PW QOS can they honor.
o The PW relative forwarding priority is set to zero.
o Path TLV is included if Disjoint Backup path is desired.
The SU-PE sends a Label Mapping message in downstream unsolicited
fashion to one or more next hop targeted LDP peers. The same PW label
is advertised to each peer. An associated use count can be maintained
to account for number of T-LDP peers the MS-PW signal was sent to.
This is useful in processing Label Release messages from the T-LDP
peers.
9.1.2. The Role of S-PE
When a PE receives a Label Mapping message, it recognizes the PW to
be of type "Multi-Segment PW" based on the PW type. The PE determines
its role as an S-PE based on the IP address of the TU-PE present in
the MS-PW TLV. Note that the rationale for using the PW type field to
recognize MS-PW processing is to cover cases such as where the TU-PE
is a T-LDP peer of the SU-PE (i.e. SS-PW), where penultimate hop S-PE
processing the MS-PW, etc.
As an S-PE, the PE must qualify itself as a suitable candidate based
on the following criteria. Note that the following check list is in
addition to normal PE behavior in support of any PW signaling message
such as MTU, sequence number, fragmentation, etc.
o Check against any configured policy (such as security, tariff,
etc) that prevents this from being a suitable S-PE for this
particular MS-PW signal.
o Examine the QOS serviceability in the appropriate direction(s)
based on the QOS TLVs and local policy, if present. Note that the
S-PE checks for resources and commits once only for a given MS-PW
as identified by the triplet {SU-PE, TU-PE, MS-PW ID}.
Shah et al Expires January 2006 [Page 15]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o If the PE knows of any suitable next hop T-LDP peer. This also
includes the case where TU-PE is its T-LDP peer.
o Decrementing the TTL results in TTL greater than zero.
o If the MS-PW FEC already exists, then the MS-PW label mapping
message is a duplicate. The S-PE handles the duplicate MS-PW label
mapping message in the following manner to determine its
suitability in propagating the signal forward:
o Based on the local policy, the S-PE is not suitable for this
MS-PW.
o If the Peer PW ID received from the predecessor for the MS-PW
FEC is not unique, S-PE is not suitable for this MS-PW.
o If the next hop T-LDP peer is not a TU-PE and the only suitable
next hop T-LDP peer is the one already selected by a previous
instance of the MS-PW signal for this MS-PW FEC, then S-PE is
not suitable for this MS-PW.
o Otherwise the S-PE is suitable. Note that allowing more than one
instance of a MS-PW label mapping to transit through an S-PE for
the same MS-PW FEC enables a previously disjoint backup path,
which converges at the S-PE, to continue forward as a partially
disjointed path.
If S-PE determines itself to be unsuitable for forwarding the MS-PW
signal, it issues the Label Release message to the sender of the
Label Mapping message.
If S-PE does determine that it is a suitable S-PE, it performs
following steps in order to forward the MS-PW signal.
o Record the Peer PW ID, PW label and senders IP address. Note that
these values are unique for each MS-PW signaling message it
receives, and in particular that the Peer PW ID is significant
only within the context of the senderÆs IP address
o Allocates the required QOS resources from the PSN tunnels in the
reverse direction.
o Determine the next hop T-LDP peer(s). If the TU-PE is a T-LDP
peer, then this PE becomes the sole candidate. If not, then the
criteria used to select the candidates are not specified in this
document, but may be based on mechanisms specified in Section 6.
The IP address of each of these is recorded.
Shah et al Expires January 2006 [Page 16]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o Allocate a new Peer PW ID and a PW label. Note that this Peer PW
ID uniquely represents this instance of MS-PW FEC.
o Increment the hop count.
o Decrement the TTL.
o Adjust the Available QOS TLV, if present, based on the resources
it is willing to commit for the PW in the reverse direction.
o If a use count is maintained, set the use count to the number of
T-LDP peers to which the MS-PW Label Mapping will be advertised.
o Record the state of the PW.
o If Path TLV is present, insert the S-PE's LSR Identifier.
The IP address of the SU-PE, MS-PW ID and TU-PE tuple along with the
newly created Peer PW ID can be used as the key to fetch the
information recorded for MS-PW.
9.1.3. The Role of TU-PE
The MS-PW signaling thus passes along the PW segments through one or
more S-PEs to arrive at the TU-PE. It is possible that some MS-PW
paths may perish mid-way for various reasons such as TTL becoming
zero, no suitable next hop, could not satisfy the QOS requirement,
etc. When an S-PE can not 'forward' the MS-PW signaling message, it
triggers a tear-down in the reverse direction of the MS-PW path
passing through it.
It is possible that the TU-PE may receive more than one MS-PW
signaling message. Each received MS-PW label mapping message
represents a PW path that varies from the other. The TU-PE may use
some heuristics and or policy to select one MS-PW as the primary PW
path. It is also possible to select one or more MS-PW paths as backup
PW paths.
A TU-PE performs the following procedures for each MS-PW Label
Mapping that a TU-PE receives:
o Matches the MS-PW FEC with the configured PW-FEC.
Shah et al Expires January 2006 [Page 17]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o It 'responds' to the selected S-PE from which the Label Mapping
message was received with the MS-PW FEC TLV with the reverse
direction bit set.
o A label release is sent to those S-PEs that were not selected with
reverse direction bit set.
o The TU-PE becomes the PW path terminator. For the unsuccessful
(i.e. un-selected) paths, reverse tear down is triggered by
the TU-PE.
o The TU-PE is also responsible for triggering the reverse path
selection of its choice. This choice could be based on only the
penultimate hop S-PE from which it receives the forward direction
signaling message, or by comparing the available QOS TLV from
various signaling messages.
o When a disjoint backup path is desired, the TU-PE uses the Path TLV
of the selected primary path as the exclude list to select the
backup path (during reverse signaling propagation) that is disjoint.
9.2. MS-PW Signaling in the Reverse Direction
9.2.1. The Role of the TU-PE
The TU-PE is responsible for generating the MS-PW Label Mapping
message in the reverse direction for one or more MS-PWs if
applicable. The following procedures are performed for each reverse
MS-PW signaling message:
o Set the direction flag to Reverse in the MS-PW TLV
o Allocates a Label for the Label Mapping message
o Use the Peer PW ID and MS-PW ID from the received Label Mapping
message unchanged.
o Set the "PW relative forwarding priority" field of this PW path to
the desired value. A higher priority value indicates to the SU-PE
that this path is selected over all other paths to transmit
traffic in both directions.
o Allocate the QOS resources from the PSN tunnel to the penultimate
hop S-PE.
Shah et al Expires January 2006 [Page 18]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o Issue a Label Release to the sender S-PE(s) for unselected MS-PW
Label Mapping messages for the same MS-PW FEC as identified by SU-
PE IP address, MS-PW ID and TU-PE IP address.
It is possible that an S-PE may need to release Label Mapping message
during the reverse path MS-PW establishment. The S-PE would initiate
the path tear down in the preceding and the succeeding MS-PW
segments. The tear down of the specific instance of MS-PW path
propagates in both directions towards SU-PE and TU-PE as described in
section 9.1.
9.2.2. The Role of the S-PE
When an S-PE receives the MS-PW signaling message in the reverse
direction, it fetches the MS-PW record using the Peer PW ID present
in the MS-PW signal. It verifies the PW FEC using SU-PE IP address,
MS-PW ID and TU-PE IP address triplet. Note that the sender of the
MS-PW signaling message in the reverse direction is responsible for
using the same Peer PW ID that was received when handling the
corresponding MS-PW signal in the forwarding direction. The Peer PW
ID uniquely represents a specific instance of MS-PW FEC.
If the S-PE finds that a label was already installed for this MS-PW,
i.e., this is an attempt for a backup PW path it performs following
operations,
o If Disjoint Backup Path is dictated as indicated by the flag
in the signal or a local policy, it releases the reverse
direction label back to the sending S-PE or TU-PE.
o Otherwise, it selects the predecessor PE (and thus the reverse
direction) based on the Peer PW ID it received in the signal
that represent the specific instance of MS-PW path in
forwarding direction.
The S-PE performs a check of resources in the respective direction
based on the requested or available QOS TLVs and the CAC behavior
flag present in MS-PW Label Mapping message. If resources are not
available, the S-PE initiates path teardown in both directions
towards U-PEs for this instance of MS-PW path.
Once the S-PE has selected the downstream T-LDP peer for the reverse
path, it performs following steps for processing a MS-PW Label
Mapping in the reverse direction,
Shah et al Expires January 2006 [Page 19]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
o The S-PE has a record of the MS-PW created during forward
processing of the same MS-PW signaling message. It fetches the
predecessorÆs IP address and PW ID and inserts that in the Label
Mapping message
o Allocates a PW label for the forward data path for the Label
Mapping message
o Programs the bidirectional PW as follows,
o Forward direction (SU-PE->TU-PE) using the label advertised to
the downstream T-LDP peer in the reverse direction MS-PW
signaling, and the label received from the upstream neighbor
for the reverse direction of the MS-PW signaling.
o Reverse direction (SU-PE<-TU-PE) using the label received from
the upstream neighbor and the label advertised to the
downstream neighbor during MS-PW signaling in the forward
direction.
o Allocates the required QOS resources from the PSN tunnels in the
forward and reverse direction.
o For all the predecessor's T-LDP peers that had advertised a MS-PW
Label Mapping in the forwarding direction but were not selected
for reverse path, the S-PE issues a Label Release message.
An S-PE may also receive a Label Release message for the MS-PW signal
that it had sent in the forwarding direction. As noted earlier, Peer
PW ID in the Label Release message represents a specific instance of
MS-PW path. However, when an S-PE is a fork for the MS-PW paths in
the forwarding direction, more than one instance of MS-PW paths map
to a single MS-PW path in reverse direction. In such case, a 'use
count' variable may be maintained. When the use count becomes zero
when decrementing for each reverse path Label Release message
received, a Label Release message is generated in the reverse path
towards the SU-PE.
9.2.3. The Role of SU-PE
The SU-PE is expected to receive one, or more if backup PWs are
supported, MS-PW signaling messages in the reverse direction. If more
than one Label Mapping message was received, the SU-PE will start
forwarding traffic using the label of the highest priority PW. It
will also expect to receive traffic over the label of that same PW.
In that case, a bi-directional, possibly multi-segmented, pseudo-wire
Shah et al Expires January 2006 [Page 20]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
has been set up between SU-PE and TU-PE. As a last step, the SU-PE
performs PW programming in its forwarding database to enable the
dataflow between the Attachment Circuit and the pseudo wire.
The SU-PE may also receive a set of Label Release messages, which
denote unsuccessful attempts to establishing the multi-segment PWs
through different paths. These messages are processed for clean-up
purposes.
It is also possible that none of the MS-PW signaling messages reached
the TU-PE and resulted in Label Release messages returning back for
the whole set. The SU-PE may choose to schedule a retry for such
cases or wait for operator intervention.
9.3. Signaling role
As per the discussion above the following is true.
1. SU-PE always
o Generates Label Mapping message (MS-PW Signal) in forward
direction.
o Processes Label Mapping message (MS-PW Signal) in reverse
direction.
2. TU-PE always
a. Processes Label Mapping message (MS-PW Signal) in forwarding
direction
b. Generates a Label Mapping message (MS-PW Signal) in reverse
direction in response to SU-PE MS-PW Signaling message (Label
Mapping).
3. S-PEs processes and propagates MS-PW signal in both direction.
10. PW status processing
A multi-segment PW includes the SU-PE, a set of one or more S-PEs and
a TU-PE. All members are responsible for maintaining a consistent
view of the PW status from end to end. If a defect occurs at any mid
point, the S-PE detecting the failure is responsible for generating
PW status to its preceding and succeeding T-LDP peers. Upon receipt
Shah et al Expires January 2006 [Page 21]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
of such (PW Status) messages, an S-PE is responsible for processing
and propagating along in the forwarding direction (i.e. in the
opposite direction from where it received). In essence, a PW Status
message generated at the midpoint should ripple through the rest of
the PW segments in both the directions towards the endpoints. The S-
PEs should only use forwarding/not-forwarding status and should leave
the incoming/outgoing breakdown of the status bits to the U-PEs only.
In addition, whenever an S-PE receives a PW status message, it must
check the forwarding capabilities between the two PW segments. If one
or both PSN tunnels fails, it should mark the PW status accordingly
before propagating it in the forwarding direction. This is important
for handling the simultaneous multiple midpoint failures at different
PW segments for a given multi-segment PW.
The PW Status TLV is OPTIONALLY included in the Label Mapping
messages generated by the SU-PE, S-PEs and TU-PEs.
11. Peer PW ID
Traditionally, the PW ID represents a handle that each PE uses as a
key to fetch the Pseudo wire related information. For MS-PWs, we have
introduced the MS-PW ID that resides in the MS-PW TLV. The MS-PW ID
is relevant only to U-PEs. The PW ID present in the PW FEC of the
Label Mapping message is re-defined in this proposal as Peer PW ID.
The Peer PW ID is dynamic in nature for S-PEs such that the sender of
the Label Mapping message 'allocates' a new PW ID for each received
PW FEC used in MS-PW Signal. The receiver of the Label Mapping
message is responsible for:
o Recording the PW ID of the sender.
o Using the PW ID of the sender a.k.a Peer PW ID, whenever it sends
an LDP message for MS-PW. This includes Label Messages (mapping,
withdraw and release) and Notification messages (PW status, PW QOS
updates, etc).
o Using its own PW ID when communicating with the downstream T-LDP
peer since he was the sender of the MS-PW Signal.
o There are no new PW IDs generated for the MS-PW Signal traversing
in the reverse path. That is, PW IDs are generated only when
signaling a MS-PW in forward direction.
o On the return path, each PE (starting with TU-PE) would use its
predecessor's PW ID in the PW ID FEC.
Shah et al Expires January 2006 [Page 22]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
12. Mechanisms for using Generalized ID FEC
The generalized ID FEC (GID FEC) consists of SAI, TAI and AGI
information. The SAI holds IP address (as present in LDP-ID) and
Attachment Identifier information for the SU-PE, while the TAI holds
IP address (as present in LDP-ID) and Attachment Identifier
information for the TU-PE. The AGI MAY represent the VPN identifier,
for example.
The GID FEC eliminates the need for some of the information present
in MS-PW TLV. However, for consistency, it is recommended that MS-PW
TLV should be included. It also eliminates the need for generating a
PW ID at each hop in the forwarding path as is the case PW ID FEC.
The signaling procedures for the SU-TE, S-PEs and TU-PE remain the
same as described above. Each MS-PW signaling message needs to be
processed within the context of the direction MS-PW signal is
flowing. In single-sided signaling, TU-PE does not have to be
configured with MS-PW specific information.
We note an exception to the handling of the generalized ID FEC. As
per [3], the receiver of GID FEC must respond 'immediately' either
with a corresponding Label Mapping message or with a Label Release
message. An exception is required when handling MS-PW Signaling,
whereby the recipient of the MS-PW signal must wait for corresponding
MS-PW Label Mapping, or a Label Release in the reverse direction.
This is not a significant deviation from the common practice as there
is no requirement that sender bind a Label Mapping message with a
timer and issue a Label Withdraw if a response is not received with
certain time.
13. Resiliency
The multi-segment pseudo wire set up is an involved process and the
nodal failures are not protected without having to initiate another
MS-PW setup. Hence it is prudent to provide a mechanism whereby
backup MS-PW(s) are setup during initial MS-PW establishment.
The proposed scheme described in this document is well suited for
this requirement as multi path PWs can be generated during initial
Shah et al Expires January 2006 [Page 23]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
MS-PW setup. When TU-PE receives multiple MS-PW signals, it may
select one or more Backup PW paths and set its priority in the MS-PW
TLV. The S-PEs continue to process and forward the MS-PW signaling in
the reverse direction in the same manner as the primary PW. It is
possible that reverse path signaling may not succeed. For this
reason, TU-PE should try to initiate multiple PW backup path setup
through different penultimate hop S-PEs.
The Backup PWE3(s) remain established and available to become the
primary PW. The SU-PE and TU-PE let the data flow only on the primary
PWE3. The following criteria or policies can be used by the SU-PE and
TU-PE to switch the data flow to a higher priority backup PW.
. Primary PW is torn down - e.g. in the case of a S-PE nodal
failure
. Primary PW is in the non-forwarding state for a long time e.g.
due to one or more PSN tunnel failures at mid points
In either case, switch over must be co-ordinated between SU-PE and
TU-PE.
The details of this or other schemes will be discussed in the future
revisions.
14. Scalability
In this scheme, the label resources are used efficiently. The scheme
allows a high probability of finding the most suitable PW path
without needing a crank back mechanism, creation of one or more
disjoint backup pseudo wire paths during the initial setup, etc.
Signaling overhead is minimized through the use of mechanisms
described in Section 6.
15. Aspects for Further Study
The following aspects will be addressed in a future revision:
o Applicability of this solution is addressing the requirements of
[5].
o How traffic is switched from primary to backup PWs on failure of
the primary.
o MS-PWs in the context of a carrier's carrier environment.
Shah et al Expires January 2006 [Page 24]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
16. Security Considerations
The security aspects of this solution will be discussed at a later
time.
17. Acknowledgments
The authors wish to acknowledge David Watkinson from Alcatel, Mark
Libby from Ciena and Eric Gray from Marconi for their contribution to
this proposal.
18. References
18.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[3] Martini et. Al., "Pseudowire Setup and Maintenance using LDP",
draft-ietf-pwe3-control-protocol-16.txt, March 2005 (work in
progress)
[4] Martini et. Al., "IANA Allocations for pseudo Wire Edge to Edge
Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-06.txt,
September 2004 (work in progress)
[5] Martini et al., "Requirements for inter domain Pseudo-Wires",
draft-martini-pwe3-MS-pw-requirements-01.txt, February 2005
(work in progress)
18.2. Informative References
[6] Martini et. Al., "Pseudo Wire Switching", draft-martini-pwe3-
pw-switching-02.txt, February 2005 (work in progress)
[7] Shah et al., "Qos Signaling for PW", draft-shah-pwe3-pw-qos-
signaling-02.txt, February 2005 (work in progress)
Shah et al Expires January 2006 [Page 25]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
Author's Addresses
Himanshu Shah
Ciena Corp
35 Nagog Park,
Acton, MA 01720
Email: hshah@ciena.com
Matthew Bocci
Alcatel
Voyager Place
Maidenhead
Berks, UK
Email: matthew.bocci@alcatel.co.uk
Mustapha Aissaoui
Alcatel
600 March Road
Kanata
ON, Canada
Email: mustapha.aissaoui@alcatel.com
Jason Rusmisel
Alcatel
600 March Road
Kanata
ON, Canada
Email: Jason.rusmisel@alcatel.com
Yetik Serbest
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
Email: Yetik_serbest@labs.sbc.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
Email: nabil.bitar@verizon.com
Shah et al Expires January 2006 [Page 26]
Internet-Draft Multi-segment Pseudo-Wire Signaling 2005
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.
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. By submitting this Internet-Draft, I certify that
any applicable patent or other IPR claims of which I am aware have
been disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shah et al Expires January 2006 [Page 27]
