Internet DRAFT - draft-balus-mh-pw-control-protocol
draft-balus-mh-pw-control-protocol
PWE3 Working Group
Internet Draft
Expires: January 2006
David McDysan Florin Balus
MCI Mike Loomis
Jeff Sugimoto
Yuichiro Wada Nortel
NTT Communications
Andy Malis
Mike Duckett Tellabs
Bellsouth
Paul Doolan
Yeongil Seo Mangrove Systems
Korea Telecom
Prayson Pate
Chris Metz Overture Networks
Cisco Systems
Vasile Radoaca
Ping Pan Consultant
Hammerhead Systems
July 2005
Multi-Segment Pseudowire Setup and Maintenance using LDP
draft-balus-mh-pw-control-protocol-02.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."
Balus et.al Expires July 2006 Page 1
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
[MS PWE3 Requirements] describes the requirements to allow a service
provider to extend the reach of pseudo-wires across multiple
domains. A Multi-Segment PW is defined as a set of two or more
contiguous PW segments that behave and function as a single point-
to-point PW.
The current specification of the PW Architecture [PW ARCH] defines
the PW as a single Segment entity, connecting the Attachment
Circuits between two Ultimate PEs (U-PE). The current procedures for
establishing a single segment PW (SS-PW) is described in [PW
Control], where typically an LDP session is established between the
ultimate PEs handling the Pseudowire End Service (PWES). No
intermediate nodes, between the PEs, are aware of the PW.
The purpose of this draft is to specify new LDP extensions, end to
end signaling procedures to address the related requirements
specified in [MS-PWE3 Requirements]. The proposed procedures follow
the guidelines defined in [RFC3036bis] and enable the usage of
addressing schemes (L2FECs) and other TLVs already defined for PWs
in [PW Control].
The solution described in the draft provides a MS-PW Operational
Model, Signaling Procedures consistent with the regular (SS-)PWs, in
order to enable seamless implementation, deployment. The resulting
MS-PW building blocks accommodate and enhance LDP-VPLS, VPWS
solutions with minimal changes in the Information Models and
Software Modules related to the L2VPN functionality.
Balus et.al. Expires January 2006 Page 2
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
Table of Contents
1. Terminology...................................................3
2. Introduction and Scope........................................4
3. Relevant SS and MS-PW Architectures...........................4
4. Motivations and Resulting Design Requirements.................6
4.1 Satisfy the MS-PW requirements in [MS PWE3 Requirements].....6
4.1.1 Scalability and Inter-Domain Signaling and Routing.........6
4.1.2 Signaling Requirements.....................................7
4.2 Operational Consistency with SS-PWs..........................8
4.2.1 Service Identification and Provisioning Models.............8
4.2.2 OAM........................................................8
4.3 Service Resiliency...........................................9
5. Information Model for Dynamic Signaling of MS-PWs.............9
5.1 MS-PW TLV Design............................................10
6. Signaling Procedures.........................................12
6.1 Ensuring both MS-PW directions traverse the same U/S-PEs....12
6.2 LDP Signaling Walkthrough...................................13
6.3 Using common LDP Signaling procedures for MS and SS-PWs.....15
6.4 Determining the Next Signaling Hop..........................15
6.4.1 Static Provisioning of the next-signaling-hop.............15
6.4.2 "Discovery" Mechanisms for the next-signaling-hop.........16
7. Service Resiliency...........................................17
8. OAM Considerations...........................................17
8.1 MS-PW Capabilities..........................................18
8.1.1 PW Status Capability Negotiation..........................18
8.1.2 VCCV Capability Negotiation...............................18
8.2 PW Status Notification Operation............................18
8.3 VCCV Operation..............................................18
9. Security Considerations......................................19
10. IANA Considerations..........................................19
11. Acknowledgements.............................................19
12. Appendix: Example of Signaling Procedures....................19
13. Full Copyright Statement.....................................21
14. Intellectual Property Statement..............................21
15. References...................................................21
16. Authors' Information.........................................22
1. Terminology
The terminology used in this document is consistent with the
terminology used in [MS PWE3 Requirements]:
. Ultimate PE (U-PE). A PE where the customer-facing ACs
(attachment circuits) are bound to a PW forwarder. An ultimate
PE is present in the first and last segments of a MS-PW.
. Single-Segment PW(SS-PW). A PW setup directly between two U-PE
devices. Each LSP in one direction of a SS-PW traverses one PSN
tunnel that connects the two U-PEs.
Balus et.al. Expires January 2006 Page 3
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
. Multi-Segment PW (MS-PW). A static or dynamically configured
set of two or more contiguous PW segments that behave and
function as a single point-to-point PW. Each end of a MS-PW by
definition MUST terminate on an U-PE.
. PW Switching Provider Edge S-PE. A PE capable of switching the
control and data planes of the preceding and succeeding PW
segments in a MS-PW. It is therefore a PW switching point for a
MS-PW. A PW Switching Point is never both U-PE and S-PE for the
same MS-PW. A PW switching point runs necessary protocols to
setup and manage PW segments with other PW switching points and
ultimate PEs.
. PW Segment. A part of a Single-Segment or Multi-Segment PW,
which is set up between two adjacent PE devices, U-PEs and/or
S-PEs.
. Extended LDP session (E-LDP). An LDP session established using
targeted discovery mode [RFC3036bis]
2. Introduction and Scope
[MS PWE3 Requirements] describes the requirements to allow a service
provider to extend the reach of pseudo-wires across multiple
domains. A MS-PW is defined as a set of two or more contiguous PW
segments that behave and function as a single point-to-point PW.
The current specification of the PW Architecture [PW ARCH] defines
the PW as a single Segment entity, connecting attachment circuits on
exactly two PEs. The current procedures for establishing PWs are
described in [PW Control], where typically an LDP session is
established between the PEs handling the pseudowire end service
(PWES). The LDP session is referred to as "targeted" because it uses
a targeted discovery (via hello messages) to establish an LDP
session between the two PEs exchanging the PW labels. The tandem
nodes between the PEs are unaware of the PW and are only involved
with establishing a PSN tunnel between the (U-)PEs.
The purpose of this draft is to specify new LDP extensions and end
to end signaling procedures to address the requirements specified in
[MS PWE3 Requirements].
The proposed procedures follow the guidelines defined in
[RFC3036bis] and enable the reuse of existing addressing schemes
(L2FECs) and other TLVs already defined for SS-PWs in [PW Control].
3. Relevant SS and MS-PW Architectures
The following two figures describe the reference models [MS PWE3
Requirements] to support SS and MS-PW emulated services.
Balus et.al. Expires January 2006 Page 4
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
|<-------------- 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 ethernet service native ethernet service
Figure 1: PWE3 Reference Configuration
Figure 1 shows the PWE3 reference architecture [PWE3-ARCH]. This
architecture applies to the case where a PSN tunnel extends between
two edges of a single PSN domain to transport a PW with endpoints at
these edges.
Native |<-----------Pseudo Wire----------->| Native
Layer2 | | Layer2
Service | |<-PSN1-->| |<--PSN2->| | Service
(AC) V V (AC)
| +----+ +-----+ +----+ |
+----+ | |UPE1|======== | SPE |=========|UPE2| | +---+
| |----------|.......PW1....|.........PW2...|---------|----| |
| CE1| | | | | | | | |CE2|
+----+ | |=========| |=========| | +---+
^ +----+ +-----+ +----+ ^
| Provider Edge 1 ^ Provider Edge 2 |
| (Ultimate-PE1) | (Ultimate-PE2) |
| PW switching point |
| (Optional PW adaptation function) |
| |
|<------------------- Emulated Service ----------------->|
Figure 2: MS-PW Reference Model
Balus et.al. Expires January 2006 Page 5
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
Figure 2 extends this architecture to show a Multi-Segment case.
UPE1 and UPE2 provide a Pseudowire from CE1 to CE2. Each UPE resides
in a different PSN domain. A PSN domain may correspond to a single
Provider's network or to a subset of nodes within a Provider
network. A PSN tunnel extends from UPE1 to SPE across PSN1, and a
second PSN tunnel extends from SPE to UPE2 across PSN2.
PWs are used to connect the Attachment circuits (ACs) attached to
UPE1 to the corresponding ACs attached to UPE2. The PW segment on
the tunnel across PSN1 is switched to a PW segment in the tunnel
across PSN2 at SPE to complete the Multi-Segment PW (MS-PW) between
UPE1 and UPE2. S-PE is therefore a PW switching point node and will
be referred to as the PW switching provider edge (S-PE). PW segments
of the same MS-PW (e.g., PW1 and PW2) MUST be of the same PW type,
but PSN tunnels (e.g., PSN1 and PSN2) can be the same or different
technology.
Note that although Figure 2 only shows a single S-PE, a PW may
transit more than one S-PE along its path.
4. Motivations and Resulting Design Requirements
This section describes the motivations and highlights the
architectural objectives of the proposal.
4.1 Satisfy the MS-PW requirements in [MS PWE3 Requirements]
4.1.1 Scalability and Inter-Domain Signaling and Routing
If a MS-PW deployment extends to large and far reaching portions of
one or more networks, mandating an E-LDP session between all
switching points of a MS-PW may lead to a control plane scalability
issue [MS PWE3 Requirements]. Some network topologies have a natural
hierarchy, as described in the use cases section of [MS PWE3
Requirements]. For example, multiple providers who wish to provide
PWs that span two or more networks will likely have a relatively
small number of gateway nodes as switching points (S-PE) that
provide access to a larger number of end nodes (U-PE) forming a
hierarchy. As another example, in some MPLS access network
topologies, it is foreseeable that thousands or even tens of
thousands of U-PE nodes may specify a small number of gateway nodes
as switching points (S-PE) for access to the MPLS backbone, breaking
the overall MPLS network into a well established hierarchy of MPLS
"domains".
In a more generic sense, [MS PWE3 Requirements] discusses a number
of cases of a PW Service that has to span multiple domains: e.g.
Inter-Provider, Inter-AS (same provider), MAN-WAN. In any of these
Balus et.al. Expires January 2006 Page 6
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
cases the interaction between domains is controlled by certain
gateways with a specific set of requirements for each individual
scenario.
This proposal eliminates the requirement for an E-LDP session
between every pair of U-PE nodes for which a PW is required while at
the same time preserving the necessary end to end signaling
properties. In doing so it alleviates the control plane scalability
requirements described in the previous paragraphs. Our proposal
enables the end to end PW signaling through a "chain" of (E-)LDP
sessions, using a dynamically determined set of S-PEs. If the S-PE
and U-PE are identified by IP addresses, then IP routing protocols
can distribute information to facilitate dynamic selection of a set
of PEs between a Source U-PE and a Destination U-PE based upon
parameters (e.g., metric, TE constraints, BGP attributes). U-PE
reachability information could be reduced by assignment of IP
address prefixes and/or prefix aggregation by a routing protocol.
There could also be some Inter-Provider scenarios where the U-PEs
located in a certain Provider domain may not be permitted to
communicate directly via an (E)-LDP session to a U-PE in a different
domain for operational and security reasons. For other reasons
(e.g., security, administrative, etc.) the local U-PE may have no
knowledge of the IP address of the remote U-PE. The requirements for
these valid scenarios are still being specified and it is not clear
whether or not a solution for dynamic end to end signaling is
required or even allowed.
A solution for these scenarios is for further study.
4.1.2 Signaling Requirements
The signaling described in this proposal is based on extensions to
[RFC3036bis] and [PW Control]. The new elements (section 6) provide
a flexible model that permits interoperability with manual
provisioning models, but also enable an end to end MS-PW to be
established with minimal number of OSS touches, ideally only one as
specified in [MS PWE3 Requirements]. Specifically, the proposal
enables the dynamic creation of an end-to-end MS-PW that does not
require any manual intervention at the S-PE nodes.
This draft allows for either the same set of S-PE nodes to be
traversed in each direction of the MS-PW, or a different set.
[Segmented PW] specifies the case where the set of intermediate S-
PEs is manually configured and the PW is stitched at these points by
matching the L2FEC for each segment and associating this with the
next segment. This case is not precluded by, and could interoperate
Balus et.al. Expires January 2006 Page 7
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
with, the method described in this document.
4.2 Operational Consistency with SS-PWs
In a Service Provider network it is understood that SS and MS-PWs
will co-exist, possibly for an indefinite amount of time.
Furthermore, it is foreseeable that existing SS-PWs may one day be
forced to migrate to a MS-PW scenario for a number of reasons. In
any case, it should be an advantage to vendors developing PW
implementations as well as providers of PW services to minimize the
differences between SS and MS-PWs. Operationally, the procedures for
identifying (addressing), provisioning and troubleshooting a SS or a
MS-PW should be similar.
4.2.1 Service Identification and Provisioning Models
[PW CONTROL] specifies that a PW is uniquely associated with a set
of connection identifiers: i.e. PWID (& U-PE pair) for PWID FEC or
AGI, AII1, AII2 for the Generalized ID FEC. This proposal reuses the
same service identifiers as SS-PW (PWID and Generalized ID FEC) to
identify MS-PWs.
From a provisioning perspective, this proposal is consistent with
the existing models for SS-PWs. For MS-PWs, both a single ended and
double ended model are possible as defined by [L2VPN SIGN], with no
user intervention required at any S-PE node.
In a MS-PW scenario, the S-PE nodes are aware of the PW. In the case
of PWID addressing, in order to reuse the service identifiers for
SS-PWs, the unique association between the U-PE pair and the PWID
FEC must be maintained when transiting through the S-PE nodes. In
the Generalized ID case a PW is identified by <PE1, <AGI, AII1>,
PE2, <AGI, AII2>> in one direction and by <PE2, <AGI, AII2>, PE1,
<AGI, AII1>> in the reverse direction [L2VPN SIGN].
This document proposes some extensions to LDP to address the
requirements described above for consistent operational model across
different PW types. The proposed solution re-uses the same L2FEC
definitions as in [PW CONTROL] for identifying the virtual
connections and a similar service provisioning model.
The proposal does not preclude the use or support of existing Auto-
discovery procedures (e.g. BGP-AD, RADIUS).
4.2.2 OAM
It is important to support the end to end PW OAM concepts already
described in [VCCV] and [PW Control]. To meet this requirement, the
Balus et.al. Expires January 2006 Page 8
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
S-PE must participate in the negotiation of the PW OAM options and
Status TLV.
The current definition of PW OAM functions (e.g. VCCV (LSP-Ping,
BFD)) [VCCV] are specified only for operation on a U-PE to U-PE
basis. This means that the concatenation of PW switching of S-PEs
in MS-PW appears as a PSN tunnel to the PW OAM function.
Support for PW OAM on a U-PE to S-PE, or S-PE to S-PE segment basis,
will require changes in the OAM messages and procedures to indicate
whether the OAM message is intended for the destination U-PE,
intermediate S-PEs, or both.
4.3 Service Resiliency
Several MPLS mechanisms exist today, including procedures defined in
[RFC3036bis], [MPLS FRR], [Grace RS] etc. This draft does not
preclude the use of any of these mechanisms.
From a MS-PW perspective, Service Resiliency refers to the ability
to choose a backup path in case of failure of the existing MS-PW
path (including S-PE failure or any segment failure) [MS PWE3
Requirements].
5. Information Model for Dynamic Signaling of MS-PWs
In the current (SS) PW Architecture (see figure 1), the setup and
maintenance of the PW connection is based on a direct, E-LDP Session
between PE1 and PE2. As a result of the bidirectional nature of PWs,
there is an association between the L2FEC, Source and Destination U-
PEs. This association is derived from the information related to the
(E-)LDP session between PEs and it is used as part of the end to end
message exchange.
In the case of a MS-PW (see figure 2), there is not an E-LDP session
between U-PE1 and U-PE2. Instead two LDP Sessions are to be used to
establish the MS-PW connection: LDP1 between U-PE1 and S-PE, LDP2
between U-PE2 and S-PE.
The procedures defined in [PW Control] can not be applied to achieve
the end to end signaling of the MS-PW. Specifically:
. the identity of the PW endpoints can no longer be derived from
the attributes of the local LDP session
. the PWID U-PE pair association is lost. PWID becomes globally
unique
. for the Generalized ID the direct association between PW and
<<PE1, <AGI, AII1>, PE2, <AGI, AII2>> respectively <PE2, <AGI,
AII2>, PE1, <AGI, AII1>> is lost.
Balus et.al. Expires January 2006 Page 9
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
. the forwarding of received Label Mapping (LM) messages is not
allowed
In order to support dynamic end to end signaling [MS PWE3
Requirements], while maintaining a consistent operational model with
SS-PW, there is a need to maintain the relationships between L2FEC
and PW endpoints (as discussed above) that are lost when the direct
LDP session is not available. This document proposes transporting
the address of the Source and Destination U-PEs in the related LDP
messages transiting through S-PE node(s). The L2FEC in combination
with the source and destination U-PE information form unique PW
endpoint identifiers; for example using the GID FEC, the TAI and
destination U-PE information will be unique, similarly for the
source U-PE and SAI information.
This information could be transported in a number of ways: via new
"fields" inserted in the existing Generalized ID FEC or via a new
LDP TLV. Choosing one vehicle versus the other is orthogonal to the
concepts described in this document as long as the Source and
Destination information together with the corresponding L2FEC is
explicitly carried in the signaling message and used to identify,
route the PW signaling message from source to destination U-PE.
We describe, in section 5.1, the details of the LDP TLV approach as
it ensures backwards compatibility with existing deployments,
offering support for both PWID and Generalized ID FECs.
Details of the Generalized ID FEC usage is for further study
5.1 MS-PW TLV Design
We are introducing a new TLV, the Multi-Segment PW TLV, which is
appended by the Source U-PE to the LDP messages related to a MS-PW.
The following format is being proposed:
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| MS-PW TLV (TBD) | MS-PW TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Source) U-PE (Mandatory) |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Destination) U-PE (Mandatory) |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Balus et.al. Expires January 2006 Page 10
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
- UF bits 00 - U equal 0 means that if the receiving PE does not
understand the TLV, a notification must be returned to the message
originator and the entire message must be ignored.
- MS-PW TLV (TBD) - To be assigned by IANA. Identifies this TLV as a
MS-PW. The presence of this TLV in LDP messages indicates this is a
MS-PW.
- MS-PW TLV Length - Specifies the total length in octets of the
TLV.
- Source U-PE (Mandatory) - The address of the originating U-PE
(e.g. U-PE1). In most of the cases it carries the IP loopback
address of the Source U-PE, although other address types - e.g.
IPv6, NSAP - could be supported.
This field is used by a MS-PW Network Element for maintaining the
uniqueness of PWID FECs and, optionally, in single sided
provisioning the discovery of the remote U-PE by the Destination U-
PE. When double sided provisioning is used, it is used to verify the
remote U-PE against the provisioned value.
- Destination U-PE (Mandatory) - The address of the Destination U-PE
(e.g. U-PE2)
Its value could be provisioned at the Source U-PE or is determined
as part of the single-sided provisioning behavior [L2VPN SIGN].
The Destination U-PE address field is used to select the next hop
through the MS-PW domains.
The basic construct used to carry the Address of the Source and
Destination U-PEs is the Prefix Element which is defined below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Type | FLAGS | PreLen | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Prefix (contd) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Prefix Type - one octet quantity. It encodes the address type for
the address prefix in the Prefix field. Initial formats supported
are:
- IPv4 0x01
- IPv6 0x02
- NSAP 0x03
Addition of other formats (or combinations of existing ones) for
Balus et.al. Expires January 2006 Page 11
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
further study: for example, AS Numbers, URLs etc.
- FLAGS - One octet field. The field is reserved for future use:
i.e. MUST be set to zero when transmitting a message and MUST be
ignored at the receiving PE.
- PreLen
One octet unsigned integer containing the length in bits of the
address prefix that follows.
- Prefix Value
An address prefix encoded according to the Prefix type field, whose
length, in bits, was specified in the PreLen field, padded to a byte
boundary.
6. Signaling Procedures
The following are generic procedures for signaling of an MS-PW.
Note that we are using throughout the next sections, examples based
on existing IP Loopbacks (as U-PE addresses) and references to IP
routing procedures.
According to section 6.1 of [MS PW Requirements]: "MS-PWs are
composed of SS-PW, and SS-PW are bi-directional, therefore both
directions of a PW segment MUST terminate on the same S-PE/U-PE". In
other words both directions of a MS-PW should traverse the same set
of S-PEs/U-PEs.
Next section introduces the concepts, procedures that ensure
compliance of the solution described in this document with the above
requirement. Note that should this requirement change (e.g. "MUST"
to "MAY terminate [..]") to enable for diverse S-PEs paths, our
solution could accommodate both options.
6.1 Ensuring both MS-PW directions traverse the same U/S-PEs
The proposed procedure is based on an "Ordered" establishment of the
individual PW segments that belong to a certain MS-PW. In other
words, the signaling is initiated only from the "originating" U-PE
node (selected based on provisioned information at nodal/PW level).
Any S-PEs or the other U-PE will not initiate a LM Message for the
setup of a MS-PW until it receives an incoming LM message for that
MS-PW.
We will refer to the direction from the originating U-PE node to the
other U-PE node as the "Forward" direction of a MS-PW. The Forward
Balus et.al. Expires January 2006 Page 12
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
direction describes the direction of the LDP label mapping messages
rather than the direction of the user dataplane. The Reverse
direction is the opposite logic, describing the direction towards
the originating U-PE node.
The following section first discusses the signaling in the "Forward"
direction followed by a brief description of the deltas in the
"Reverse" direction. Note that the flags from the destination U-PE
field (see section 5.1) may be used to indicate directionality/
behavior in determining the next-signaling-hop.
6.2 LDP Signaling Walkthrough
The following section focuses on the step by step, generic signaling
procedures involved in the setup of a MS-PW. The procedures involved
in discovery of Next Signaling Hop are referenced in section 6.4.
1. The PW FEC (PWID or Generalized ID) and Destination U-PE is
provisioned on both U-PEs. If single sided provisioning or auto
discovery is used, the Destination U-PE needs only to be
configured on one of the U-PEs.
2. The originating U-PE builds the MS-PW TLV by inserting its local
address in the Source U-PE field and the address of Destination
U-PE in the Destination U-PE field. The MS-PW TLV and optional
TLVs, (e.g. QOS TLV) are appended to the LM message which is sent
to the Next Signaling Hop. The next signaling hop towards the dU-
PE can be determined by referencing the PW end point information
against the MS-PW information disseminated as per section 6.4.
3. When the next signaling hop receives the LM message, it verifies
a PSN tunnel exists to the upstream MS-PW NE. If a PSN tunnel is
not available a label release message is sent. However if the S-
PE and the next signaling hop are directly connected, with no P
device between them, the PSN tunnel may not be necessary [PW
Control].
4. OAM parameters (VCCV, Status TLV support) are validated. If the
request cannot be supported a label release message is sent to
the upstream MS-PW NE.
5. If QoS information* was included in the LM message, the local NE
performs a CAC against the selected PSN Tunnel to requesting NE.
If the CAC fails a label release message is sent. Alternatively,
based on Service Provider choice an increase in the capacity of a
PSN tunnel may be tried to accommodate the bandwidth requirements
of the MS-PW.
Balus et.al. Expires January 2006 Page 13
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
6. If the Destination U-PE address does not equal the MS-PW NE
address, a new label mapping message is generated and sent to the
Next Signaling Hop, with the original L2FEC and MS-PW TLV,
replacing just the value of the service label in the Label TLV
with one from its own label space. Note that the S-PE should not
comply with the text of section 5.2.3 of [PW Control] i.e. should
not initiate a LM message in the opposite direction towards U-PE1
("Ordered" Mode). Go to step 3.
7. When the Destination U-PE receives the LM message containing the
MS-PW TLV (the value from the destination U-PE field matches the
address of the local Network Element), it attempts to match the
L2 FEC with its local provisioning.
a) If the L2 FEC and the Source U-PE address do not match the
local provisioning, a label release message is sent.
b) If the L2 FEC is not provisioned, the label maybe retained
by virtue of liberal label retention
8. The remaining Destination U-PE processing of the PW label mapping
message is as defined in PWE3 control signaling standard [PW
Control] (see also tasks outlined in steps 3-5). This completes
the Signaling in the Forward direction.
9. MS-PW Signaling in the Reverse direction starts. The (new) source
U-PE and subsequently the S-PEs in the Reverse direction will
perform the tasks described in steps 2-8.
The next hop at any S-PE is determined by referencing the LDP
sessions used to setup the LSP in the Forward direction. The
particular LDP Session is determined using the index (dU-PE,
TAI/PWID) information from the LM message received from the
Reverse direction. The association between (L2FEC, sU-PE, dU-PE)
and the incoming LDP session is stored as the PW Segments are
established. This information is always required for further
Control Plane Exchanges (e.g. Label Release, PW Status) but is
used to also setup the MS-PW in the Reverse direction.
* The term "QoS Information" is used here to mean either one or both
of Quantity (e.g. Bandwidth) and/or Quality (e.g. DiffServ) of
Service. The detailed definition of the TLVs used to signal this
information is outside the scope of this document. Description of
possible TLV structures could be found in [TSPEC] and respectively
[RFC3270].
Balus et.al. Expires January 2006 Page 14
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
6.3 Using common LDP Signaling procedures for MS and SS-PWs
In addition to the OSS and Operational consistency between SS [PW
Control] and MS-PWs concepts described in this document, it would be
preferable to have consistent procedures used in the Network
Elements in order to minimize implementation deltas.
If the U/S-PEs support the signaling procedures described in the
previous section for MS-PWs, then these Network Elements could use
consistent procedures to establish also SS-PWs between them.
In this context it is important to note that steps 1-9 are the same
for both SS/MS-PWs. The only difference between a SS/MS-PW is the
amount of times the procedure cycles through steps 3-6: i.e. in the
SS-PW case, the first receiving PE (see step 6) will determine that
the destination U-PE is itself and the source U-PE is the same with
the originator of the LDP session on which the LM message was
received. As a result it will run right away through the remaining
of the steps (7-9) instead of cycling 1/more times through steps 3-6
as for a MS-PW.
6.4 Determining the Next Signaling Hop
To support end-to-end dynamic signaling of MS-PWs, information must
be present in MS-PW aware nodes to support the determination of the
next signaling hop. Such information can be provisioned on each MS-
PW system or disseminated via regular routing protocols (e.g. BGP).
The following section describes procedures that could be used to
"discover" the next-signaling-hop in MS-PW aware systems.
6.4.1 Static Provisioning of the next-signaling-hop
The simplest way to build next-signaling-hop knowledge is by static
provisioning. The provisioning of the next-signaling-hop (e.g. S-PE)
is similar to the way IP static routes/default gateways are
provisioned: e.g. in a U-PE at the nodal level, a default S-PE is
provisioned manually when the MS-PW feature is enabled. This can be
a simple and effective method, when the network topology is simple
and well defined.
As long as the U-PE prefixes from one domain can be summarized the
static method could be also expanded to entire domains: i.e. all the
U-PEs in one domain being represented by 1/just a few static entries
of this sort: U-PE Prefix (47.0.0.0/8), NH = S-PE1. At the other
extreme, when special treatment is required for a certain PW a
"fully qualified" entry could be provisioned: e.g. AGI (40),U-PE1
(47.1.1.1), AII (200) -> NH (S-PE1).
Balus et.al. Expires January 2006 Page 15
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
Note that static provisioning may be used in combination with
dynamic discovery. Indeed, some PW domains may use static
provisioning while other PW domains along the multi-hop signaling
path may use dynamic discovery within their domain. An example of
this scenario is where many U-PEs in a given network will always use
a well known primary and backup S-PE "gateways" as the next hop.
This S-PE gateway may have many possible S-PE peers and may use a
dynamic discovery mechanism to determine the next-signaling-hop of
its S-PE peer for a given MS-PW.
6.4.2 "Discovery" Mechanisms for the next-signaling-hop
The next-signaling-hop selection can also be determined by
dynamically learning, for each PW Domain, the association between
the (Destination U-PE and optionally TAI/PWID) and the next-
signaling-hop.
There could be several mechanisms that allow dynamic discovery,
advertisement of the next-signaling-hop. The focus of this section
is on how this can be accomplished with BGP-based procedures. Note
that these procedures may have an end-to-end scope (e.g. Inter-AS
Use Case) or may be limited just to the <Core> PW Domain (e.g. MAN-
WAN Use Case), depending upon the availability of BGP in the related
MS-PW capable nodes.
The signaling procedures described in this draft are compatible and
make use of the L2VPN provisioning models and related AD procedures
described in [L2VPN SIGN] and respectively [BGP AD].
If the Source U-PE knows apriori the address of the Destination U-
PE, there is no need to advertise a "fully qualified" address on a
per PW Attachment Circuit. The Destination U-PE may
advertise only its Prefix address (and not the Attachment <Circuit>
Identifier (AI)) as part of well known BGP auto-discovery procedures
- see [BGP AD], [L2VPN SIGN].
As PW Endpoints are provisioned in the U-PEs, the Source U-PE will
use this information to obtain the first S-PE hop (i.e., first BGP
next hop) where the first PW segment will be established and
subsequent S-PEs will use the same information (i.e. the next BGP
next-hop(s)) to obtain the next-signaling-hop(s) on the path to the
Destination U-PE.
This is not an exhaustive list, merely examples of how discovery can
be accomplished using BGP. It can also be envisioned, in some
particular scenarios, that IGP with TE extensions could be used to
control the selection of the next-signaling-hop, while avoiding non
MS-PW aware devices (e.g. Ps, 2547 PEs).
Balus et.al. Expires January 2006 Page 16
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
7. Service Resiliency
With the introduction of dynamic determination of the intermediate
S-PEs, this proposal introduces the possibility of end to end (as
well as segment) connection resiliency for MS-PWs.
For failures between MS-PW elements, this document does not preclude
any existing MPLS failure recovery mechanisms from being used (i.e.
[MPLS FRR]).
For failures that prevent one MS-PW system from establishing a PW
segment to the succeeding MS-PW system (e.g. U-PE to S-PE), this
document adopts the procedures described in section 6 to allow for
the dynamic selection of intermediate next hops for the purpose of
service resiliency. For example, a source U-PE node can select a
candidate S-PE next hop via local preference (or via any other
metrics) for the purpose of service resiliency.
Several options are possible for service resiliency and a simple
example is provided here, with further optimizations to be explored
in future revisions of the document. Existing MPLS or PSN tunnel
recovery mechanisms must be attempted before the procedures
described below.
As a result of the MS-PW following the same forward and reverse
path, we propose that only the upstream node from the failure in the
forward path make the next hop selection. This provides consistency
with the procedures used to establish the original MS-PW (described
in section 6), where the forward path determines the backwards path
as well. Recall that each MS-PW system is already aware of the
direction of the MS-PW signaling, and its relation to that direction
for any particular MS-PW L2 FEC, sU-PE, dU-PE triplet. The MS-PW
segments downstream from the failure MUST be released as a new path
may be selected that does not overlap with the previous path.
If alternate routing is not possible at the closest MS-PW node
upstream from the failure, that node must release the PW segment to
the next upstream MS-PW system to attempt additional rerouting.
8. OAM Considerations
This section deals with the Negotiation of the OAM Capabilities
described in [VCCV], where the OAM functions (e.g. VCCV (LSP-Ping,
BFD)) are specified only for operation on a U-PE to U-PE basis.
Support for PW OAM on a U-PE to S-PE, or S-PE to S-PE segment basis,
require changes in the OAM messages and procedures to indicate
whether the OAM message is intended for the destination U-PE,
Balus et.al. Expires January 2006 Page 17
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
intermediate S-PEs, or both. These changes are for further study.
8.1 MS-PW Capabilities
Common OAM capabilities should be supported on all U-PE and S-PE
nodes in the MS-PW. MS-PW takes a least common denominator approach
to OAM. The minimum OAM functionality supported on a MS-PW is label
withdraw.
8.1.1 PW Status Capability Negotiation
PW Status capability is negotiated across the MS-PW when the MS-PW
is first setup. Support for PW status notification is indicated by
the presence of the status TLV in the label mapping message.
PW Status capability negotiation at the U-PE occurs as described in
[PWE3 CNTL].
It is strongly recommended that MS-PW implement PW status TLV.
8.1.2 VCCV Capability Negotiation
VCCV capability is negotiated across the MS-PW when the MS-PW is
first setup. Support for VCCV is indicated by the presence of the
VCCV parameter in the interfaces parameter TLV. This parameter is
included in the label mapping message within the parameter TLV as
described in [VCCV]
VCCV capability negotiation at the U-PE occurs as described in
[VCCV]
An S-PE successfully negotiates VCCV capability for the MS-PW when
it support VCCV itself and the label mapping messages from its
upstream and downstream neighbors indicate support for VCCV for a
given MS-PW FEC.
8.2 PW Status Notification Operation
PW Status notification at the U-PE occurs as described in [PWE3
CNTL].
When an S-PE receives a PW status notification message, the message
is processed at the S-PE and propagated down stream along the
control path.
8.3 VCCV Operation
VCCV operation at the MS-PW Network Element (NE) occurs as described
in [VCCV], with the S-PEs transparently forwarding these messages
Balus et.al. Expires January 2006 Page 18
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
towards the destination U-PE.
Support for MS-PW segment OAM, trace-route is for further study.
9. Security Considerations
To be addressed later.
10. IANA Considerations
A new TLV code point needs to be allocated by IANA for MS-PW TLV.
11. Acknowledgements
The editors gratefully acknowledge the following contributors: Luca
Martini, Nabil Bitar, Richard Spencer, Simon Delord, Bruce Davie,
Elizabeth Hache, Hamid Ould-Brahim, Praveen Muley, Arashmid
Akhavain.
12. Appendix: Example of Signaling Procedures
The following section discusses an example of an end to end
signaling walkthrough for a MS-PW using the architecture depicted in
Figure 2.
Let us assume that Double-sided provisioning and Generalized ID FEC
are being used to set up the MS-PW built using segments PW1 and PW3
and using LDP1 and LDP2 sessions.
Here are the required steps:
1. Service Provisioning
a) at U-PE1: AGI = 40, SAII=100, TAII=200, Remote PE = U-PE2
(IP2 loopback), Origin = Yes
b) at U-PE2: AGI = 40, SAII=200, TAII=100, Remote PE = U-PE1
(IP1 loopback);
2. The originating U-PE (U-PE1 in our example) builds the MS-PW TLV
by inserting its loopback address in the Source U-PE field and
the address of U-PE2 in the Destination U-PE field. Next it
appends the MS-PW TLV to the label mapping message associating
the provisioned FEC information - i.e. (40,100,200) - with the
corresponding PW service label.
Balus et.al. Expires January 2006 Page 19
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
3. Using the address of Destination U-PE (U-PE2), U-PE1 selects the
next signaling hop (S-PE) determined by referencing the PW end
point information - IP2,40,200 - against the MS-PW information
disseminated as per section 6.4.
4. On receipt of the LM message, S-PE performs the following tasks:
Verifies it has a PSN tunnel to U-PE1. If no tunnel is found a
label release message is sent.
a) Verifies it can support the requested OAM parameters (VCCV,
Status TLV support). If the request cannot be supported a
label release message is sent to U-PE1.
b) If QoS information* was included in the LM message, it
performs a CAC against the selected PSN Tunnel to U-PE1. If
the CAC fails a label release message is sent to U-PE1.
Alternatively, based on Service Provider choice, an
increase in the capacity of the PSN tunnel may be tried to
accommodate the bandwidth requirements of the MS-PW.
c) Checks to see if it is the Destination U-PE by comparing
the address within the MS-PW TLV d-UPE field with its own
address. If the addresses are not the same, S-PE looks for
a next signaling hop to get to U-PE2 - see step 3 above.
Then it signals the final segment of the MS-PW by
generating and forwarding a new label mapping message to U-
PE2, with the original L2FEC (40,100,200) and MS-PW TLV
(IP1, IP2), replacing just the value of the service label
in the Label TLV with one from its own label space.
5. When U-PE2 receives the LM message containing the MS-PW TLV, it
performs tasks outlined in step 4.
6. U-PE2 then attempts to match the L2 FEC with its local
provisioning.
a) If the FEC information and the U-PE1 address do not match
the local provisioning, a label release message is sent.
b) If the FEC information (40,200,100) is not yet provisioned,
the label may be retained by virtue of liberal label
retention.
7. The remaining U-PE2 processing of the PW label mapping message is
defined in PWE3 control signaling [PW Control].
8. MS-PW Signaling in the Reverse direction U-PE2 to U-PE1 starts.
The U-PE2 and subsequently S-PE will perform the tasks described
in steps 2-7. The next hop at U-PE2 and S-PE is determined by
referencing the LDP sessions used to setup the LSP in the Forward
direction. The particular LDP Session is determined in the U-PE2
Balus et.al. Expires January 2006 Page 20
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
and S-PE using the index (IP1,TAI(40,100)) from the LM message
received from the Reverse direction.
13. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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.
14. 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,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
15. References
[RFC3036bis] Andersson, Minei, Thomas. "LDP Specification" draft-
Balus et.al. Expires January 2006 Page 21
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
ietf-mpls-rfc3036bis-01.txt, IETF Work in Progress, November 2004
[MS PWE3 Requirements] Martini et al. "Requirements for inter domain
Pseudo-Wires", draft-ietf-pwe3-ms-pw-requirements-00.txt, IETF Work
in Progress, June 2005
[PW Control] Martini et.al. "Pseudowire Setup and Maintenance using
LDP", draft-ietf-pwe3-control-protocol-17.txt, IETF Work in
Progress, June 2005
[VCCV] Nadeau et.al., "Pseudo Wire (PW) Virtual Circuit Connection
Verification (VCCV)", draft-ietf-pwe3-vccv-03.txt, June 2004
[L2VPN SIGN] Rosen et. al. "Provisioning Models and Endpoint
Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-03.txt,
IETF Work in Progress, February 2005
[Segmented PW] Martini et.al. " Segmented Pseudo Wire", draft-ietf-
pwe3-segmented-pw-00.txt, IETF Work in Progress, July 2005
[RFC3270] Le Faucheur, et. al. "MPLS Support of Differentiated
Services", RFC 3270, May 2002
[TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997
16. Authors' Information
Andrew G. Malis
Tellabs, Inc.
2730 Orchard Parkway
San Jose, CA, USA 95134
Email: Andy.Malis@tellabs.com
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
Email: chmetz@cisco.com
David McDysan
MCI
22001 Loudoun County Pkwy
Ashburn, VA, USA 20147
dave.mcdysan@mci.com
Florin Balus
Nortel
3500 Carling Ave.
Ottawa, Ontario, CANADA
balus@nortel.com
Balus et.al. Expires January 2006 Page 22
Internet Draft draft-balus-mh-pw-control-protocol-02 July, 2005
Jeff Sugimoto
Nortel
3500 Carling Ave.
Ottawa, Ontario, CANADA
sugimoto@nortel.com
Mike Duckett
Bellsouth
Lindbergh Center
D481
575 Morosgo Dr
Atlanta, GA 30324
e-mail: mduckett@bellsouth.net
Mike Loomis
Nortel
600, Technology Park Dr
Billerica, MA, USA
mloomis@nortel.com
Paul Doolan
Mangrove Systems
IO Fairfield Blvd
Wallingford, CT, USA 06492
pdoolan@mangrovesystems.com
Ping Pan
Hammerhead Systems
640 Clyde Court
Mountain View, CA, USA 94043
e-mail: ppan@hammerheadsystems.com
Prayson Pate
Overture Networks, Inc.
507 Airport Blvd, Suite 111
Morrisville, NC, USA 27560
Email: prayson.pate@overturenetworks.com
Yuichiro Wada
NTT Communications
3-20-2 Nishi-Shinjuku, Shinjuke-ku
Tokyo 163-1421, Japan
yuichiro.wada@ntt.com
Yeongil Seo
Korea Telecom Corp.
463-1 Jeonmin-dong, Yusung-gu
Daejeon, Korea
syi1@kt.co.kr
Balus et.al. Expires January 2006 Page 23
