PWE3 Working Group Florin Balus (Ed.)
Internet Draft Nortel
Expires: June 2006 Luca Martini (Ed.)
Cisco Systems Inc.
Matthew Bocci (Ed.)
Alcatel
December 2005
Dynamic Placement of Multi Segment Pseudo Wires
draft-ietf-pwe3-dynamic-ms-pw-00.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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
There is a requirement for service providers to be able to extend the
reach of pseudo wires ( PW ) across multiple Public Switched Network
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. This document describes extensions to the PW control
protocol to dynamically place the segments of the multi segment
pseudo wire among a set of Provider Edge Routers.
Balus, et al. [Page 1]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
Table of Contents
1 Specification of Requirements ........................ 3
2 Major Co-authors ..................................... 3
3 Acknowledgements ..................................... 3
4 Introduction ......................................... 3
4.1 Scope ................................................ 3
4.2 Terminology .......................................... 4
4.3 Architecture Overview ................................ 4
5 Applicability ........................................ 6
5.1 Requirements Addressed ............................... 6
5.2 Changes to Existing PW Signaling ..................... 6
5.3 PW layer 2 addressing ................................ 6
5.3.1 Attachment Circuit Addressing ........................ 7
5.3.2 S-PE addressing ...................................... 7
6 Dynamic placement of MS-PWs .......................... 8
6.1 LDP Signaling ........................................ 8
6.1.1 MS-PW Next Hop Bandwidth Signaling ................... 8
6.2 Path selection and next hop determination ............ 9
6.2.1 AII PW routing table Lookup aggregation rules ........ 10
6.2.2 PW Static Route ...................................... 10
6.2.3 Dynamic advertisement with BGP ....................... 11
6.3 Active/Passive T-PE Election Procedure ............... 11
6.4 Detailed Signaling Procedures ........................ 11
7 Failure Handling Procedures .......................... 12
7.1 PSN Failures ......................................... 13
7.2 S-PE Failures ........................................ 13
8 Support for Explicit PW Path ......................... 13
9 Operations and Maintenance (OAM) ..................... 13
10 Use of FEC 128 ....................................... 14
11 Security Considerations .............................. 14
12 IANA Considerations .................................. 15
12.1 LDP Status Codes ..................................... 15
12.2 Interface Parameter Sub-TLV type ..................... 15
13 Full Copyright Statement ............................. 15
14 Intellectual Property Statement ...................... 16
15 Normative References ................................. 16
16 Informative References ............................... 17
17 Author Information ................................... 17
Balus, et al. [Page 2]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
1. Specification of Requirements
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
2. Major Co-authors
The editors gratefully acknowledge the following additional co-
authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan,
Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff
Sugimoto.
3. Acknowledgements
The editors also gratefully acknowledge the input of the following
people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile
Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada.
4. Introduction
4.1. Scope
[MS-REQ] describes the service provider requirements for extending
the reach of pseudo-wires across multiple PSN domains. This is
achieved using a Multi-segment Pseudo-Wire (MS-PW). 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. This architecture is
described in [MS-ARCH].
The procedures for establishing PWs that extend across a single PWE3
domain are described in [PWE3-CTRL], while procedures for setting up
PWs across multiple domains, or control planes are described in [PW-
SEG].
The purpose of this draft is to specify extensions to the PWE3
control protocol [PWE3-CTRL], and [PW-SEG] procedures, to enable
multi-segment PWs to be automatically placed. The proposed procedures
follow the guidelines defined in [RFC3036bis] and enable the reuse of
existing TLVs, and procedures defined for SS-PWs in [PWE3-CTRL].
Balus, et al. [Page 3]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
4.2. Terminology
[MS-ARCH] provides terminology for multi-segment pseudo wires.
This document defines the following additional terms:
- Source Terminating PE (ST-PE). A Terminating PE (T-PE), which
assumes the active signaling role and initiates the signaling for
multi-segment PW.
- Target Terminating PE (TT-PE). A Terminating PE (T-PE) that
assumes the passive signaling role. It waits and responds to the
multi-segment PW signaling message in the reverse direction.
- Forward Direction: ST-PE to TT-PE.
- Reverse Direction: TT-PE to ST-PE
- Forwarding Direction: Direction of control plane, signaling flow
- Pseudo wire Routing (PW routing). The dynamic placement of SS-PWs
that compose an MS-PW, as well as the automatic selection of S-
PEs.
4.3. Architecture Overview
The following figure describes the reference models which are derived
from [MS-ARCH] to support PW emulated services across multi-segment
PWs.
Balus, et al. [Page 4]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
Native |<-------------Pseudo Wire----------->| Native
Service | | Service
(AC) | |<-PSN1-->| |<-PSN2-->| | (AC)
| V V V V V V |
| +-----+ +-----+ +-----+
+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
| |-------|.....PW.Seg't1........PW Seg't3......|----------| |
| CE1| | | | | | | | | |CE2 |
| |-------|.....PW.Seg't2.......|PW Seg't4......|----------| |
+----+ | | |=========| |=========| | | +----+
^ +-----+ +-----+ +-----+ ^
| Provider Edge 1 ^ Provider Edge 2 |
| | |
| | |
| PW switching point |
| |
|<------------------- Emulated Service -------------------->|
Figure 1: PW switching Reference Model
Figure 1 shows the architecture for a simple multi-segment case. T-
PE1 and T-PE2 provide PWE3 to CE1 and CE2. These PEs reside in
different PSNs. A PSN tunnel extends from T-PE1 to S-PE1 across PSN1,
and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PWs
are used to connect the attachment circuits (ACs) attached to T-PE1
to the corresponding AC attached to T-PE2. A PW on the tunnel across
PSN1 is connected to a PW in the tunnel across PSN2 at S-PE1 to
complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1
is therefore the PW switching point and will be referred to as the PW
switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are
segments of the same MS-PW while PW Segment 2 and PW Segment 4 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, and PSN tunnels (e.g., PSN1
and PSN2) can be the same or different technology. An S-PE switches
an MS-PW from one segment to another based on the PW identifiers. (
PWid , or AII ) How the Pw PDUs are switched at the S-PE depends on
the PSN tunnel technology: in case of an MPLS PSN to another MPLS PSN
PW switching the operation is a standard MPLs label switch operation.
Note that although Figure 1 only shows a single S-PE, a PW may
transit more one S-PE along its path. For instance, in the multi-
provider case, there can be an S-PE at the border of one provider
domain and another S-PE at the border of the other provider domain.
Balus, et al. [Page 5]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
5. Applicability
In this document we describe the case where the PSNs carrying the
SS-PW are only MPLS PSNs using the generalized FEC 129. Furthermore,
we consider the case of a ST-PE and/or TT-PE supporting FEC 128 only
and which establish a MS-PW through a network of FEC 129 S-PEs.
Interactions with an IP PSN using L2TPv3 as described in [PW-SEG]
section 7.4 are left for further study.
5.1. Requirements Addressed
Specifically the following requirements are addressed - see [MS-REQ]:
- Dynamic End-to-end Signaling
- Scalability and Inter-domain Signaling and Routing
- Minimal number of provisioning touches (provisioning only at the
T-PEs)
- Same set of T-PEs/S-PEs for both directions of a MS-PWs
- QoS Signaling, Call Admission Control
- Resiliency
- End-to-end negotiation of OAM Capability
5.2. Changes to Existing PW Signaling
The procedures described in this document make use of existing LDP
TLVs and related PW signaling procedures described in [PWE3-CTRL] and
[PW-SEG]. Only an optional Bandwidth TLV is added to address the QoS
Signaling requirements (see "MS-PW Next Hop Bandwidth Signaling"
section for details).
5.3. PW layer 2 addressing
Single segment pseudo wires on an MPLS PSN use the PWID for
addressing a PW using FEC 128, and Attachment circuit identifiers for
a PW using FEC 129. In the case of an automatically placed MS-PW,
there is a requirement to have individual global addresses assigned
to PW attachment circuits, for reachability , and manageability of
the PW. Referencing figure 1 above, individual globally unique
addresses MUST be allocated to all the ACs , and S-PEs composing an
MS-PW.
Balus, et al. [Page 6]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
5.3.1. Attachment Circuit Addressing
The attachment circuit addressing is derived from [AII] AII type 2
shown here:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Implementations of the following procedure MUST interpret the AII
type to determine the meaning the address format of the AII,
irrespective of the number of segments in the MS-PW.
A unique combination Global ID, Prefix, and AC ID parts of the AII
type 2 will be assigned to each AC. In general the same global ID and
prefix will be assigned for all ACs belonging to the same T-PE,
however this is not a strict requirement. A particular T-PE might
have more than one prefix assigned to it, and likewise a fully
qualified AII with the same Global ID/Prefix but different AC IDs
might belong to different T-PEs.
For the purpose of MS-PW the AII MUST be globally unique across all
interconnected PW domains.
5.3.2. S-PE addressing
The T-PE may elect to select a known specific path along a set of S-
PEs for a specific PW. This requires that each S-PE be uniquely
addressable in terms of pseudo wires. For this purpose at least one
AI address of the format similar to AII type 2 [AII] composed of the
Global ID, and Prefix part only MUST be assigned to each S-PE.
Balus, et al. [Page 7]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
6. Dynamic placement of MS-PWs
[PW-SEG] describes a procedure for connecting multiple pseudo wires
together. This procedure requires each S-PE to be manually configured
with the information required to terminate and initiate the SS-PW
part of the MS-PW. The procedures in the following sections describe
an method to extend [PW-SEG] by allowing the automatic selection of
pre-defined S-PEs, and automatically setting up a MS-PW between two
T-PEs.
In this document we consider the case where the PSNs carrying the
SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions
with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are
left for further study.
6.1. LDP Signaling
The LDP signaling procedures are described in [PWE3-CTRL] and
expanded in [PW-SEG]. No new LDP Signaling components are required
for setting up a basic automatically placed MS-PW. However some
optional signaling extensions are described below.
6.1.1. MS-PW Next Hop Bandwidth Signaling
In the SS-PW case the PW QoS requirements may easily be met by
selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS
requirements. However in the case of an automatically placed MS-PW
the QoS requirements for a SS-PW not initiating on a T-PE MAY need to
be indicated along with the MS-PW addressing. This is accomplished by
including an OPTIONAL PW Bandwidth TLV. The PW Bandwidth TLV is
specified as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW BW TLV (0x096E) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The complete definitions of the content of the SENDER_TSPEC objects
are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to
the datapath in the direction of ST-PE to TT-PE. The reverse
Balus, et al. [Page 8]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE.
In the forward direction, after a next hop selection is determined, a
T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine
an appropriate PSN tunnel towards the next signaling hop. If such a
tunnel exists, the MS-PW signaling procedures are invoked with the
inclusion of the PW Bandwidth TLV.
When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is
selected, the S/T-PE MUST request the appropriate resources from the
PSN. The resources described in the reverse SENDER_TSPEC are
allocated from the PSN toward the originator of the message or
previous hop. When resources are allocated from the PSN for a
specific PW, then the PSN SHOULD account for the PW usage of the
resources.
In the case where PSN resources towards the previous hop are not
available the following procedure MUST be followed:
-i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to
the PSN tunnel.
-ii. The S-PE MAY attempt to setup another PSN tunnel to
accommodate the new PW QoS requirements.
-iii. If the S-PE cannot get enough resources to setup the segment
in the MS-PW a label release MUST be returned to the
previous hop with a status message of "Bandwidth resources
unavailable"
In the latter case, the T-PE receiving the status message MUST also
withdraw the corresponding PW label mapping for the opposite
direction if it has already been successfully setup.
6.2. Path selection and next hop determination
The AII type 2 described above contains a Global ID, Prefix, and AC
ID. The global ID , and the Prefix are used by S-PEs to determine the
next SS-PW destination for LDP signaling.
Once an S-PE receives a PW Setup message containing a TAII with an
AII that is not locally present, the S-PE performs a lookup in a
local Layer 2 AII PW routing table. If this lookup results in an IP
address of the next PE that advertised reachability information for
the AII in question, then the S-PE will initiate the necessary LDP
messaging procedure for setting up the next PW segment. If the AII PW
routing table lookup does not result in a IP address of the next PE,
the destination AII has become unreachable, and the PW MUST fail to
setup. In this case a label release MUST be returned to the T-PE with
a status message of "AII Unreachable".
Balus, et al. [Page 9]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
To allow for dynamic end-to-end signaling of MS-PWs, information must
be present in S-PEs to support the determination of the next PW
signaling hop. Such information can be provisioned (static route
equivalent) on each S-PE system or disseminated via regular routing
protocols (e.g. BGP).
6.2.1. AII PW routing table Lookup aggregation rules
All PEs capable of dynamic multi segment pseudowire path selection,
must build a PW routing table to be used for PW next hop selection.
The PW addressing scheme (AII type 2 in [AII]) consists of a Global
Id, a 32 bit prefix and a 32 bit Attachment Circuit ID.
An aggregation scheme similar with the one used for classless IPv4
addresses can be employed. An (8 bits) length mask is specified as a
number ranging from 0 to 112 that indicates which Least Significant
Bits (LSB) are ignored in the address field when performing the PW
address matching algorithm.
0 47 48 79 80 111 (bits)
+------------+--------+--------+
| Global ID | Prefix | AC ID |
+------------+--------+--------+
During the signaling phase, the content of the (fully qualified) TAII
type 2 field from the FEC129 TLV is compared against routes from the
PW Routing table. Similar with the IPv4 case, the route with the
longest match is selected, determining the next signaling hop and
implicitly the next PW Segment to be signaled.
6.2.2. PW Static Route
For the purpose of determining the next signaling hop for a segment
of the pseudo wire, the PEs MAY be provisioned with fixed route
entries in the PW next hop routing table. The static PW entries will
follow all the addressing rules and aggregation rules described in
the previous sections. The most common use of PW static provisioned
routes is the "default" route entry as follows:
Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling
Hop = S-PE1
Balus, et al. [Page 10]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
6.2.3. Dynamic advertisement with BGP
T-PE, And S-PEs, MAY choose to use [MP-BGP] to propagate PW address
information throughout the PSN.
In the case of the MS-PW if the Source T-PE knows apriori the address
of the Terminating T-PE, there is no need to advertise a "fully
qualified" address on a per PW Attachment Circuit. Only the T-PE
Global ID, Prefix, and prefix length needs to be advertised as part
of well known BGP procedures - see [MP-BGP], [L2VPN-SIG]. The
specific details, and encoding of the PW routing information in BGP
are outside the scope of this document.
As PW Endpoints are provisioned in the T-PEs, the ST-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 TT-PE.
6.3. Active/Passive T-PE Election Procedure
When a MS-PW is signaled, Each T-PE might independently start
signaling the MS-PW, this could result in a different path selected
for each T-PE PW. To avoid this situation one of the T-PE MUST start
the PW signaling ( active role ), while the other waits to receive
the LDP label mapping before sending the respective PW LDP label
mapping message. ( passive role ). The Active T-PE (the ST-PE) and
the passive T-PE (the TT-PE) MUST be identified before signaling is
initiated for a given MS-PW. The determination of which T-PE assume
the active role SHOULD be done as follows: the SAII and TAII are
compared as unsigned integers, if the SAII is bigger then the T-PE
assumes the active role.
The selection selection process to determine which T-PE assumes the
active role MAY be superseded by manual provisioning.
6.4. Detailed Signaling Procedures
On receiving a label mapping message, the S-PE MUST inspect the FEC
TLV.
If the receiving node has no local AII matching the TAII for that
label mapping then the S-PE will check if the FEC is already
installed for the forward direction:
Balus, et al. [Page 11]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
- If it is already installed, and the received mapping was received
from the same LDP peer where the forward LDP label mapping was
sent, then this label mapping represents signaling in the reverse
direction for this MS-PW segment.
- Otherwise this represents signaling in the forward direction.
For the forward direction:
-i. Determine the next hop S-PE or T-PE according to the
procedures above.
-ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE.
If no tunnel exists to the next hop S-PE or T-PE the S-PE
MAY attempt to setup a PSN tunnel.
-iii. Check that a PSN tunnel exists to the previous hop. If no
tunnel exists to the previous hop S-PE or T-PE the S-PE MAY
attempt to setup a PSN tunnel.
-iv. If the S-PE cannot get enough PSN resources to setup the
segment to the next or previous S-PE or T-PE, a label
withdraw MUST be returned to the T-PE with a status message
of "Resources Unavailable".
-v. If the label mapping message contains a Bandwidth TLV,
allocate the required resources on the PSN tunnels in the
forward and reverse directions according to the procedures
above.
-vi. Install the FEC for the forward direction.
-vii. Allocate a new PW label for the forward direction.
-viii. Send the label mapping message with the new forward label
and the FEC to the next hop S-PE/T-PE.
For the reverse direction:
-i. Install the FEC for the reverse direction.
-ii. Determine the next signaling hop by referencing the LDP
sessions used to setup the LSP in the Forward direction.
-iii. Install the FEC for the reverse direction.
-iv. Allocate a new PW label for the reverse direction.
-v. Send the label mapping message with a new label and the FEC
to the next hop S-PE/ST-PE.
7. Failure Handling Procedures
Balus, et al. [Page 12]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
7.1. PSN Failures
Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the
PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD
follow the procedures defined in Section 8 of [PW-SEG].
7.2. S-PE Failures
For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be
followed. However the ST-PE MAY re-signal the PW if an alternate
path is available.
8. Support for Explicit PW Path
The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be
used to signal an explicit path for a MS-PW. An Explicit PW path may
be required to provide a simple solution for 1:1 protection with
diverse primary and backup path or to enable controlled signaling
(strict or loose) for special PWs. Details of its usage to be
provided in a future version.
9. Operations and Maintenance (OAM)
The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A
PW switching point TLV is used [PW-SEG] to record the switching
points that the PW traverses.
In the case of a MS-PW where the PW Endpoints are identified though
using a globally unique, FEC 129-based AII addresses, there is no
PWID defined on a per segment basis. Each individual PW segment is
identified by the address of adjacent S-PE(s) in conjunction with the
SAII and TAII.
In this case, the following type MUST be used in place of type 0x01
in the PW switching point TLV:
Type Length Description
0x04 10 Global ID/Prefix of the S-PE
The above field MUST be included together with type 0x02 in the TLV
once per individual PW Switching Point following the same rules and
procedures as described in [PW-SEG].
Balus, et al. [Page 13]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
10. Use of FEC 128
FEC 128 is defined in [PWE3-CTRL] for signaling single segment PWs.
Where the first segment or last of a MS-PW uses FEC 128, and
intermediate segments use FEC 129, the procedures in Section 6.1.3 of
[PW-SEG] must be followed with the extensions described below. The
interface parameters of the FEC 128 segment MUST include the global
ID, prefix and AC ID for the TT-PE. These are contained in the FEC
128 Interface Parameters Sub-TLV and used to signal the first FEC 129
MS-PW segment at the S-PE.
The interface parameter Sub-TLV type "TT-PE TAII" is defined of value
TBD.
The format of these interface parameter sub TLVs is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first S-PE along the MS-PW path will then use globally unique AII
as the SAII for this MS-PW. The allocation of this AII is achieved as
follows:
-i. The Gloabal ID is provisioned on the local S-PE.
-ii. The Remote FEC 128 LDP peer LDP router Id is used as the
Prefix field of the AII.
-iii. The Fec 128 PW ID is used as the AC ID field of the AII.
11. Security Considerations
This document specifies only extensions to the protocols already
defined in [PWE3-CTRL], and [PW-SEG]. Each such protocol may have
its own set of security issues, but those issues are not affected by
the extensions specified herein. Note that the protocols for
dynamically distributing PW Layer 2 reachability information may have
their own security issues, however those protocols specifications are
outside the scope of this document.
Balus, et al. [Page 14]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
12. IANA Considerations
This document uses several new LDP TLV types, IANA already maintains
a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The
following value is suggested for assignment:
TLV type Description
0x096E Bandwidth TLV
12.1. LDP Status Codes
This document uses several new LDP status codes, IANA already
maintains a registry of name "STATUS CODE NAME SPACE" defined by
RFC3036. The following value is suggested for assignment:
Assignment E Description
TBD 0 "Bandwidth resources unavailable"
TBD 0 "Resources Unavailable"
TBD 0 "AII Unreachable"
12.2. Interface Parameter Sub-TLV type
This document uses a new Interface Parameter Sub-TLV type, IANA
already maintains a registry of name "Interface Parameter Sub-TLV
type" defined by [IANA]. The following value is suggested for
assignment:
Assignment Description
TBD "TT-PE TAII"
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.
Balus, et al. [Page 15]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
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.
15. Normative References
[PWE3-IANA] 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)
[PW-SEG] 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
[RFC3036bis] Andersson, Minei, Thomas. "LDP Specification"
draft-ietf-mpls-rfc3036bis-01.txt, IETF Work in Progress,
November 2004
[PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", Martini L.,et al
draft-ietf-pwe3-control-protocol-17.txt, ( work in progress ),
June 2005.
Balus, et al. [Page 16]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
[AII] "AII Types for Aggregation", Chris M., et al
draft-metz-aii-aggregate-01.txt, October 2006 (work in progress)
16. Informative References
[BRADNER] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MS-REQ] Martini et al, "Requirements for Inter-domain Pseudo-Wires",
draft-ietf-pwe3-ms-pw-requirements-00, Martini, et al.,June 2005
[RFC3985] Bryant, et al., "PWE3 Architecture", RFC3985.
[MS-ARCH] Bocci at al, "Architecture for Multi-Segment PWE3",
draft-bocci-bryant-pwe3-ms-pw-arch-01.txt, September 2005.
( work in progress )
[L2VPN-SIG] E. Rosen, et Al. "Provisioning, Autodiscovery,
and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-06.txt,
September 2005 ( work in progress )
[MP-BGP] Bates, T., Rekhter, Y., Chandra, R. and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
17. Author Information
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
e-mail: lmartini@cisco.com
Matthew Bocci
Alcatel Telecom Ltd,
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
e-mail: matthew.bocci@alcatel.co.uk
Balus, et al. [Page 17]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
Florin Balus
Nortel
3500 Carling Ave.
Ottawa, Ontario, CANADA
e-mail: balus@nortel.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
e-mail: nabil.bitar@verizon.com
Himanshu Shah
Ciena Corp
35 Nagog Park,
Acton, MA 01720
e-mail: hshah@ciena.com
Mustapha Aissaoui
Alcatel
600 March Road
Kanata
ON, Canada
e-mail: mustapha.aissaoui@alcatel.com
Jason Rusmisel
Alcatel
600 March Road
Kanata
ON, Canada
e-mail: Jason.rusmisel@alcatel.com
Yetik Serbest
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
e-mail: Yetik_serbest@labs.sbc.com
Balus, et al. [Page 18]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
Andrew G. Malis
Tellabs, Inc.
2730 Orchard Parkway
San Jose, CA, USA 95134
e-mail: Andy.Malis@tellabs.com
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
e-mail: chmetz@cisco.com
David McDysan
MCI
22001 Loudoun County Pkwy
Ashburn, VA, USA 20147
e-mail: dave.mcdysan@mci.com
Jeff Sugimoto
Nortel
3500 Carling Ave.
Ottawa, Ontario, CANADA
e-mail: 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
e-mail: mloomis@nortel.com
Balus, et al. [Page 19]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-00.txt December 2005
Paul Doolan
Mangrove Systems
IO Fairfield Blvd
Wallingford, CT, USA 06492
e-mail: 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
e-mail: prayson.pate@overturenetworks.com
Vasile Radoaca
radoaca@hotmail.com
Yuichiro Wada
NTT Communications
3-20-2 Nishi-Shinjuku, Shinjuke-ku
Tokyo 163-1421, Japan
e-mail: yuichiro.wada@ntt.com
Yeongil Seo
Korea Telecom Corp.
463-1 Jeonmin-dong, Yusung-gu
Daejeon, Korea
e-mail: syi1@kt.co.kr
Balus, et al. [Page 20]
