diff options
Diffstat (limited to 'doc/rfc/rfc7267.txt')
| -rw-r--r-- | doc/rfc/rfc7267.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc7267.txt b/doc/rfc/rfc7267.txt new file mode 100644 index 0000000..9ebfb6f --- /dev/null +++ b/doc/rfc/rfc7267.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Martini, Ed. +Request for Comments: 7267 Cisco Systems, Inc. +Updates: 6073 M. Bocci, Ed. +Category: Standards Track F. Balus, Ed. +ISSN: 2070-1721 Alcatel-Lucent + June 2014 + + + Dynamic Placement of Multi-Segment Pseudowires + +Abstract + + RFC 5254 describes the service provider requirements for extending + the reach of pseudowires (PWs) across multiple Packet 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 pseudowire among a set of Provider Edge (PE) routers. This + document also updates RFC 6073 by updating the value of the Length + field of the PW Switching Point PE Sub-TLV Type 0x06 to 14. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7267. + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 1] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 2] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Scope ......................................................4 + 1.2. Specification of Requirements ..............................4 + 1.3. Terminology ................................................4 + 1.4. Architecture Overview ......................................5 + 2. Applicability ...................................................6 + 2.1. Changes to Existing PW Signaling ...........................6 + 3. PW Layer 2 Addressing ...........................................6 + 3.1. Attachment Circuit Addressing ..............................7 + 3.2. S-PE Addressing ............................................8 + 4. Dynamic Placement of MS-PWs .....................................8 + 4.1. Pseudowire Routing Procedures ..............................8 + 4.1.1. AII PW Routing Table Lookup Aggregation Rules .......9 + 4.1.2. PW Static Route .....................................9 + 4.1.3. Dynamic Advertisement with BGP .....................10 + 4.2. LDP Signaling .............................................11 + 4.2.1. Multiple Alternative Paths in PW Routing ...........13 + 4.2.2. Active/Passive T-PE Election Procedure .............14 + 4.2.3. Detailed Signaling Procedures ......................15 + 5. Procedures for Failure Handling ................................16 + 5.1. PSN Failures ..............................................16 + 5.2. S-PE Failures .............................................17 + 5.3. PW Reachability Changes ...................................17 + 6. Operations, Administration, and Maintenance (OAM) ..............18 + 7. Security Considerations ........................................18 + 8. IANA Considerations ............................................19 + 8.1. Correction ................................................19 + 8.2. LDP TLV Type Name Space ...................................19 + 8.3. LDP Status Codes ..........................................20 + 8.4. BGP SAFI ..................................................20 + 9. References .....................................................20 + 9.1. Normative References ......................................20 + 9.2. Informative References ....................................21 + 10. Contributors ..................................................22 + 11. Acknowledgements ..............................................23 + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 3] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +1. Introduction + +1.1. Scope + + [RFC5254] describes the service provider requirements for extending + the reach of pseudowires across multiple Packet Switched Network + (PSN) domains. This is achieved using a multi-segment pseudowire + (MS-PW). An MS-PW is defined as a set of two or more contiguous + pseudowire (PW) segments that behave and function as a single point- + to-point PW. This architecture is described in [RFC5659]. + + The procedures for establishing PWs that extend across a single PSN + domain are described in [RFC4447], while procedures for setting up + PWs across multiple PSN domains or control plane domains are + described in [RFC6073]. + + The purpose of this document is to specify extensions to the + pseudowire control protocol [RFC4447], and [RFC6073] procedures, to + enable multi-segment PWs to be dynamically placed. The procedures + follow the guidelines defined in [RFC5036] and enable the reuse of + existing TLVs, and procedures defined for Single-Segment Pseudowires + (SS-PWs) in [RFC4447]. Dynamic placement of point-to-multipoint + (P2MP) PWs is for further study and outside the scope of this + document. + +1.2. 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 [RFC2119]. + +1.3. Terminology + + [RFC5659] provides terminology for multi-segment pseudowires. + + This document defines the following additional terms: + + - Source Terminating Provider Edge (ST-PE): A Terminating Provider + Edge (T-PE) that assumes the active signaling role and initiates + the signaling for multi-segment PWs. + + - Target Terminating Provider Edge (TT-PE): A Terminating Provider + Edge (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. + + + + +Martini, et al. Standards Track [Page 4] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + - Reverse Direction: TT-PE to ST-PE. + + - Pseudowire Routing (PW routing): The dynamic placement of the + segments that compose an MS-PW, as well as the automatic selection + of Switching PEs (S-PEs). + +1.4. Architecture Overview + + The following figure shows the reference model, derived from + [RFC5659], to support PW emulated services using multi-segment PWs. + + Native |<---------Multi-Segment Pseudowire-------->| Native + Service | PSN PSN | Service + (AC) | |<--Tunnel-->| |<--Tunnel-->| | (AC) + | V V 1 V V 2 V V | + | +-----+ +-----+ +-----+ | + +---+ | |T-PE1|============|S-PE1|============|T-PE2| | +---+ + | |------|...... PW.Seg't 1....X....PW.Seg't 3.......|-------| | + |CE1| | | | | | | | | |CE2| + | |------|...... PW.Seg't 2....X....PW.Seg't 4.......|-------| | + +---+ | | |============| |============| | | +---+ + ^ +-----+ +-----+ +-----+ ^ + | Provider Edge 1 ^ Provider Edge 2 | + | | | + | | | + | PW switching point | + | | + |<-------------------- Emulated Service ------------------>| + + Figure 1: MS-PW Reference Model + + The PEs that provide services to CE1 and CE2 are Terminating PE1 + (T-PE1) and Terminating PE2 (T-PE2), respectively. A PSN tunnel + extends from T-PE1 to Switching PE1 (S-PE1), and a second PSN tunnel + extends from S-PE1 to T-PE2 . PWs are used to connect the attachment + circuits (ACs) attached to PE1 to the corresponding ACs attached to + T-PE2. + + A PW segment on PSN Tunnel 1 is connected to a PW segment on PSN + Tunnel 2 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 is + referred to as the 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 MS-PW. PW segments of the same + MS-PW (e.g., PW Segment 1 and PW Segment 3) MUST be of the same PW + type, and PSN tunnels can be of the same or a different technology. + An S-PE switches an MS-PW from one segment to another based on the PW + identifiers (PWid, or Attachment Individual Identifier (AII)). How + + + +Martini, et al. Standards Track [Page 5] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + the PW protocol data units (PDUs) are switched at the S-PE depends on + the PSN tunnel technology: in the case of a Multiprotocol Label + Switching (MPLS) PSN to another MPLS PSN, PW switching involves a + standard MPLS label swap operation. + + Note that although Figure 1 only shows a single S-PE, a PW may + transit more than one S-PE along its path. Although [RFC5659] + describes MS-PWs that span more than one PSN, this document does not + specify how the Label Distribution Protocol (LDP) is used for PW + control [RFC4447] in an inter-AS (Autonomous System) environment. + +2. Applicability + + This document describes the case where the PSNs carrying the MS-PW + are only MPLS PSNs using the Generalized Pseudowire Identifier (PWid) + Forwarding Equivalence Class (FEC) element (also known as FEC 129). + + Interactions with an IP PSN using the Layer 2 Tunneling Protocol + version 3 (L2TPv3) as described in Section 8 of [RFC6073] are left + for further study. + +2.1. Changes to Existing PW Signaling + + The procedures described in this document make use of existing LDP + TLVs and related PW signaling procedures described in [RFC4447] and + [RFC6073]. The following optional TLV is also defined: + + - A Bandwidth TLV to address QoS Signaling requirements (see + Section 4.2). + + This document also updates the value of the Length field of the PW + Switching Point PE Sub-TLV Type 0x06 to 14. + +3. PW Layer 2 Addressing + + Single-segment pseudowires on an MPLS PSN can use attachment circuit + identifiers for a PW using FEC 129. In the case of a dynamically + placed MS-PW, there is a requirement for the attachment circuit + identifiers to be globally unique, for the purposes of reachability + and manageability of the PW. Referencing Figure 1 above, individual + globally unique addresses MUST be allocated to all the ACs and S-PEs + of an MS-PW. + + + + + + + + + +Martini, et al. Standards Track [Page 6] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +3.1. Attachment Circuit Addressing + + The attachment circuit addressing is derived from AII Type 2 + [RFC5003], as 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 (continued) | Prefix | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix (continued) | AC ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AC ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: AII Type 2 TLV Structure + + The fields are defined in Section 3.2 of [RFC5003]. + + Addressing schemes based on AII Type 2 permit varying levels of AII + summarization, thus reducing the scaling burden on PW routing. PW + addressing based on AII Type 2 is suitable for point-to-point + provisioning models where auto-discovery of the address at the TT-PE + is not required. That is, it is known a priori by provisioning. + + Implementations of the following procedure MUST interpret the AII + type to determine the meaning of the address format of the AII, + irrespective of the number of segments in the MS-PW. All segments of + the PW MUST be signaled with the same AII type. + + A unique combination of Global ID, Prefix, and AC ID parts of the + AII Type 2 are assigned to each AC. In general, the same Global ID + and Prefix are be assigned for all ACs belonging to the same T-PE. + This is not a strict requirement, however. 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-PWs, the AII MUST be globally unique across all + PSNs that are spanned by the MS-PW. + + The AII for a local attachment circuit of a given T-PE of an MS-PW + and the AII of the corresponding attachment circuit on a far-end T-PE + (with respect to the LDP signaling) are known as the Source + Attachment Individual Identifier (SAII) and Target Attachment + Individual Identifier (TAII) as per [RFC6074]. + + + +Martini, et al. Standards Track [Page 7] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +3.2. S-PE Addressing + + Each S-PE MUST be assigned an address that uniquely identifies it + from a pseudowire perspective, in order to populate the PW Switching + Point PE (SP-PE) TLV specified in [RFC6073]. For this purpose, at + least one Attachment Identifier (AI) address of the format similar to + AII Type 2 [RFC5003] composed of the Global ID, and Prefix part, + only, MUST be assigned to each S-PE. + + If an S-PE is capable of dynamic MS-PW signaling but is not assigned + with an S-PE address, then on receiving a dynamic MS-PW Label Mapping + message the S-PE MUST return a Label Release with the "Resources + Unavailable" (0x38) status code. + +4. Dynamic Placement of MS-PWs + + [RFC6073] describes a procedure for concatenating multiple + pseudowires together. This procedure requires each S-PE to be + manually configured with the information required for each segment of + the MS-PW. The procedures in the following sections describe a + method to extend [RFC6073] by allowing the automatic selection of + predefined S-PEs and dynamically establishing an MS-PW between two + T-PEs. + +4.1. Pseudowire Routing Procedures + + The AII Type 2 described above contains a Global ID, Prefix, and + AC ID. The TAII is used by S-PEs to determine the next SS-PW + destination for LDP signaling. + + Once an S-PE receives an MS-PW Label Mapping message containing a + TAII with an AII that is not locally present, the S-PE performs a + lookup in a PW AII routing table. If this lookup results in an IP + address for the next-hop PE with reachability information for the AII + in question, then the S-PE will initiate the necessary LDP messaging + procedure to set up the next PW segment. If the PW AII routing table + lookup does not result in an IP address for a next-hop PE, the + destination AII has become unreachable, and the PW setup MUST fail. + In this case, the next PW segment is considered unprovisioned, and a + Label Release MUST be returned to the T-PE with a status message of + "AII Unreachable". + + If the TAII of an MS-PW Label Mapping message received by a PE + contains the Prefix matching the locally provisioned prefix on that + PE but an AC ID that is not provisioned, then the LDP liberal label + retention procedures apply, and the Label Mapping message is + retained. + + + + +Martini, et al. Standards Track [Page 8] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + 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 (equivalent to a + static route) on each S-PE, or disseminated via regular routing + protocols (e.g., BGP). + +4.1.1. AII PW Routing Table Lookup Aggregation Rules + + All PEs capable of dynamic MS-PW path selection MUST build a PW AII + routing table to be used for PW next-hop selection. + + The PW addressing scheme (AII Type 2 as defined in [RFC5003]) + consists of a Global ID, a 32-bit Prefix, and a 32-bit Attachment + Circuit ID. + + An aggregation scheme similar to that used for classless IPv4 + addresses can be employed. A length mask (8 bits) is specified as a + number ranging from 0 to 96 that indicates which Most Significant + Bits (MSBs) are relevant in the address field when performing the PW + address-matching algorithm. + + 0 31 32 63 64 95 (bits) + +-----------+--------+--------+ + | Global ID | Prefix | AC ID | + +-----------+--------+--------+ + + Figure 3: PW Addressing Scheme + + During the signaling phase, the content of the (fully qualified) + TAII Type 2 field from the FEC 129 TLV is compared against routes + from the PW routing table. Similar to 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. + +4.1.2. PW Static Route + + For the purpose of determining the next signaling hop for a segment + of the pseudowire, 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 this example of the "default" route entry as follows: + + Global ID = 0 Prefix = 0 AC ID = 0, Prefix Length = 0 + Next Signaling Hop = {IP Address of next-hop S-PE or T-PE} + + + + + + +Martini, et al. Standards Track [Page 9] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +4.1.3. Dynamic Advertisement with BGP + + Any suitable routing protocol capable of carrying external routing + information MAY be used to propagate MS-PW path information among + S-PEs and T-PEs. However, T-PEs and S-PEs MAY choose to use the + Border Gateway Protocol (BGP) [RFC4271] with the Multiprotocol + Extensions as defined in [RFC4760] to propagate PW address + information throughout the PSN. PW address information is only + propagated by PEs that are capable of PW switching. Therefore, the + multiprotocol BGP neighbor topology MUST coincide with the topology + of T-PEs and S-PEs. + + Contrary to Layer 2 VPN signaling methods that use BGP for + auto-discovery [RFC6074], in the case of the dynamically placed + MS-PW, the source T-PE knows a priori (by provisioning) the AC ID on + the terminating T-PE that signaling should use. Hence, there is no + need to advertise a "fully qualified" 96-bit address on a per-PW + attachment circuit basis. Only the T-PE Global ID, Prefix, and + prefix length need to be advertised as part of well-known BGP + procedures; see [RFC4760]. + + Since 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) to where the first PW segment will be established. Any + 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. + + The PW dynamic path Network Layer Reachability Information (NLRI) is + advertised in BGP UPDATE messages using the MP_REACH_NLRI and + MP_UNREACH_NLRI attributes [RFC4760]. The {AFI, SAFI} value pair + used to identify this NLRI is (AFI=25, SAFI=6). A route target MAY + also be advertised along with the NLRI. + + The Next Hop field of the MP_REACH_NLRI attribute SHALL be + interpreted as an IPv4 address whenever the length of the NextHop + address is 4 octets, and as an IPv6 address whenever the length of + the NextHop address is 16 octets. + + The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix + comprising an 8-octet Route Distinguisher, the Global ID, the Prefix, + and the AC ID, and encoded as defined in Section 4 of [RFC4760]. + + + + + + + + + +Martini, et al. Standards Track [Page 10] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + This NLRI is structured as follows: + + Bit + 0 7 8 71 72 103 104 135 136 167 + +------+----------------+-----------+--------+--------+ + |Length| Route Dist | Global ID | Prefix | AC ID | + +------+----------------+-----------+--------+--------+ + + Figure 4: NLRI Field Structure + + The Length field is the prefix length of the Route Distinguisher + + Global ID + Prefix + AC ID in bits. + + Except for the default PW route, which is encoded as a 0-length + Prefix, the minimum value of the Length field is 96 bits. Lengths of + 128 bits to 159 bits are invalid, as the AC ID field cannot be + aggregated. The maximum value of the Length field is 160 bits. BGP + advertisements received with invalid Prefix lengths MUST be rejected + as having a bad packet format. + +4.2. LDP Signaling + + The LDP signaling procedures are described in [RFC4447] and expanded + in [RFC6073]. No new LDP signaling components are required for + setting up a dynamically placed MS-PW. However, some optional + signaling extensions are described below. + + One of the requirements that MUST be met in order to achieve the QoS + objectives for a PW on a segment is that a PSN tunnel MUST be + selected that can support at least the required class of service and + that has sufficient bandwidth available. + + Such PSN tunnel selection can be achieved where the next hop for a PW + segment is explicitly configured at each PE, whether the PE is a T-PE + or an S-PE in the case of a segmented PW, without dynamic path + selection (as per [RFC6073]). In these cases, it is possible to + explicitly configure the bandwidth required for a PW so that the T-PE + or S-PE can reserve that bandwidth on the PSN tunnel. + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 11] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + Where dynamic path selection is used and the next hop is therefore + not explicitly configured by the operator at the S-PE, a mechanism to + signal the bandwidth for the PW from the T-PE to the S-PEs is + required. 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: PW Bandwidth TLV Structure + + The PW Bandwidth TLV fields are as follows: + + - TLV Length: The length of the value fields in octets. Value = 64. + + - Forward SENDER_TSPEC = the SENDER_TSPEC for the forward direction + of the PW, as defined in Section 3.1 of [RFC2210]. + + - Reverse SENDER_TSPEC = the SENDER_TSPEC for the reverse direction + of the PW, as defined in Section 3.1 of [RFC2210]. + + The complete definitions of the content of the SENDER_TSPEC objects + are found in Section 3.1 of [RFC2210]. The forward SENDER_TSPEC + refers to the data path in the direction ST-PE to TT-PE. The reverse + 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 the PE searches for a PSN + tunnel, any tunnel that points to a next hop equivalent to the next + hop selected will be included in the search (the LDP address TLV is + used to determine the next-hop equivalence). + + 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 + + + + + +Martini, et al. Standards Track [Page 12] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + previous hop. When resources are allocated from the PSN for a + specific PW, the allocation SHOULD account for the resource usage of + the PW. + + 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 set up another PSN tunnel to accommodate + the new PW QoS requirements. + + iii. If the S-PE cannot get enough resources to set up 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 message for the opposite + direction if it has already been successfully set up. + + If an ST-PE receives a Label Mapping message, the following procedure + MUST be followed: + + If the ST-PE has already sent a Label Mapping message for this PW, + then the ST-PE MUST check to see if this Label Mapping message + originated from the same LDP peer to which the corresponding Label + Mapping message for this particular PW was sent. If it is the same + peer, the PW is established. If it is a different peer, then the + ST-PE MUST send a Label Release message with a status code of "PW + Loop Detected" to the PE that originated the LDP Label Mapping + message. + + If the PE has not yet sent a Label Mapping message for this + particular PW, then it MUST send the Label Mapping message to this + LDP peer, regardless of what the PW TAII routing lookup result is. + +4.2.1. Multiple Alternative Paths in PW Routing + + A next-hop selection for a specific PW may find a match with a PW + route that has multiple next hops associated with it. Multiple next + hops may be either configured explicitly as static routes or learned + through BGP routing procedures. Implementations at an S-PE or T-PE + MAY use selection algorithms, such as CRC32 on the FEC TLV or flow- + aware transport of PWs [RFC6391], for load balancing of PWs across + multiple next hops, so that each PW has a single next hop. The + details of such selection algorithms are outside the scope of this + document. + + + +Martini, et al. Standards Track [Page 13] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +4.2.2. Active/Passive T-PE Election Procedure + + When an MS-PW is signaled, each T-PE might independently initiate + signaling the MS-PW. This could result in a different path being + used by each direction of the PW. To avoid this situation, one T-PE + MUST initiate PW signaling (i.e., take an active role), while the + other T-PE waits to receive the LDP Label Mapping message before + sending the LDP Label Mapping message for the reverse direction of + the PW (i.e., take a passive role). The active T-PE (the ST-PE) and + the passive T-PE (the TT-PE) MUST be identified before signaling + begins for a given MS-PW. Both T-PEs MUST use the same method for + identifying which is active and which is passive. + + A T-PE SHOULD determine whether it assumes the active role or the + passive role using procedures similar to those of [RFC5036], + Section 2.5.2, Bullet 2. The T-PE compares the Source Attachment + Individual Identifier (SAII) [RFC6074] with the Target Attachment + Individual Identifier (TAII) [RFC6074] as unsigned integers, and if + the SAII > TAII, the T-PE assumes the active role. Otherwise, it + assumes the passive role. + + The following procedure for comparing the SAII and TAII as unsigned + integers SHOULD be used: + + - If the SAII Global ID > TAII Global ID, then the T-PE is active + + - else if the SAII Global ID < TAII Global ID, then the T-PE is + passive + + - else if the SAII Prefix > TAII Prefix, then the T-PE is active + + - else if the SAII Prefix < TAII Prefix, then the T-PE is + passive + + - else if the SAII AC ID > TAII AC ID, then the T-PE is + active + + - else if the SAII AC ID < TAII AC ID, then the T-PE is + passive + + - else there is a configuration error + + + + + + + + + + +Martini, et al. Standards Track [Page 14] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +4.2.3. 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 message, then the Label Mapping message SHOULD be + forwarded on to another S-PE or T-PE. The S-PE will check to see if + the FEC is already installed for the forward direction: + + - If the FEC is already installed and the received Label Mapping was + received from the same LDP peer to which the forward LDP Label + Mapping was sent, then this Label Mapping represents signaling in + the reverse direction for this MS-PW segment. + + - If the FEC is already installed and the received Label Mapping was + received from a different LDP peer to which the forward LDP Label + Mapping was sent, then the received Label Mapping MUST be released + with a status code of "PW Loop Detected". + + - If the FEC is not already installed, then this represents signaling + in the forward direction. + + The following procedures are then executed, depending on whether the + Label Mapping was determined to be for the forward or the reverse + direction of the MS-PW. + + For the forward direction: + + i. Determine the next-hop S-PE or T-PE according to the procedures + above. If next-hop reachability is not found in the S-PE's PW + AII routing table, then a Label Release MUST be sent with + status code "AII Unreachable". If the next-hop S-PE or T-PE is + found and is the same LDP peer that sent the Label Mapping + message, then a Label Release MUST be returned with status code + "PW Loop Detected". If the SAII in the received Label Mapping + is local to the S-PE, then a Label Release MUST be returned + with status code "PW Loop Detected". + + ii. Check to see if 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 set up a PSN tunnel. + + iii. Check to see if 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 set up a PSN tunnel. + + + + + + + +Martini, et al. Standards Track [Page 15] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + iv. If the S-PE cannot get enough PSN resources to set up the + segment to the next-hop or previous-hop S-PE or T-PE, a Label + Release 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. Allocate a new PW label for the forward direction. + + vii. Install the FEC 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 received in the Label Mapping message for the + reverse direction. + + ii. Determine the next signaling hop by referencing the LDP sessions + used to set up the PW in the forward direction. + + iii. Allocate a new PW label for the next hop in the reverse + direction. + + iv. Install the FEC for the next hop in the reverse direction. + + v. Send the Label Mapping message with a new label and the FEC to + the next-hop S-PE/ST-PE. + +5. Procedures for Failure Handling + +5.1. PSN Failures + + Failures of the PSN tunnel MUST be handled by PSN mechanisms. An + example of such a PSN mechanism is MPLS fast reroute [RFC4090]. If + the PSN is unable to re-establish the PSN tunnel, then the S-PE + SHOULD follow the procedures defined in Section 10 of [RFC6073]. + + + + + + + + + + + +Martini, et al. Standards Track [Page 16] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +5.2. S-PE Failures + + For defects in an S-PE, the procedures defined in [RFC6073] SHOULD be + followed. A T-PE or S-PE may receive an unsolicited Label Release + message from another S-PE or T-PE with various failure codes, such as + "Loop Detected", "PW Loop Detected", "Resources Unavailable", "Bad + Strict Node Error", or "AII Unreachable". All these failure codes + indicate a generic class of PW failures at an S-PE or T-PE. + + If an unsolicited Label Release message with such a failure status + code is received at a T-PE, then it is RECOMMENDED that the T-PE + attempt to re-establish the PW immediately. However, the T-PE MUST + throttle its PW setup message retry attempts with an exponential + backoff in situations where PW setup messages are being constantly + released. It is also RECOMMENDED that a T-PE detecting such a + situation take action to notify an operator. + + S-PEs that receive an unsolicited Label Release message with a + failure status code SHOULD follow this procedure: + + i. If the Label Release is received from an S-PE or T-PE in the + forward or reverse signaling direction, then the S-PE MUST tear + down both segments of the PW. The status code received in the + Label Release message SHOULD be propagated when sending the Label + Release for the next segment. + +5.3. PW Reachability Changes + + In general, an established MS-PW will not be affected by next-hop + changes in AII reachability information. + + If there is a next-hop change in AII reachability information in the + forward direction, the T-PE MAY elect to tear down the MS-PW by + sending a Label Withdraw message to the downstream S-PE or T-PE. The + teardown MUST also be accompanied by an unsolicited Label Release + message and will be followed by an attempt by the T-PE to + re-establish the MS-PW. + + If there is a change in the AII reachability information in the + forward direction at an S-PE, the S-PE MAY elect to tear down the + MS-PW in both directions. A label withdrawal is sent in each + direction followed by an unsolicited Label Release. The unsolicited + Label Release messages MUST be accompanied by the status code "AII + Unreachable". This procedure is OPTIONAL. Note that this procedure + is likely to be disruptive to the emulated service. PW Redundancy + [RFC6718] MAY be used to maintain the connectivity used by the + emulated service in the case of a failure of the PSN or S-PE. + + + + +Martini, et al. Standards Track [Page 17] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + A change in AII reachability information in the reverse direction has + no effect on an MS-PW. + +6. Operations, Administration, and Maintenance (OAM) + + The OAM procedures defined in [RFC6073] may also be used for + dynamically placed MS-PWs. A PW Switching Point PE TLV [RFC6073] is + used to record the switching points that the PW traverses. + + In the case of an MS-PW where the PW Endpoints are identified by + using globally unique AII addresses based on FEC 129, there is no + pseudowire identifier (PWid) defined on a per-segment basis. Each + individual PW segment is identified by the address of the adjacent + S-PE(s) in conjunction with the SAII and TAII. + + In this case, the following TLV type (0x06) MUST be used in place of + type 0x01 in the PW Switching Point PE TLV: + + Type Length Description + ---- ------ ----------------------------------- + 0x06 14 L2 PW address of PW Switching Point + + The above sub-TLV MUST be included in the PW Switching Point PE TLV + once per individual PW switching point, following the same rules and + procedures as those described in [RFC6073]. A more detailed + description of this sub-TLV is also given in Section 7.4.1 of + [RFC6073]. However, the length value MUST be set to 14 ([RFC6073] + states that the length value is 12, but this does not correctly + represent the actual length of the TLV). + +7. Security Considerations + + This document specifies extensions to the protocols already defined + in [RFC4447] and [RFC6073]. The extensions defined in this document + do not affect the security considerations for those protocols, but + [RFC4447] and [RFC6073] do impose a set of security considerations + that are applicable to the protocol extensions specified in this + document. + + It should be noted that the dynamic path selection mechanisms + specified in this document enable the network to automatically select + the S-PEs that are used to forward packets on the MS-PW. Appropriate + tools, such as the Virtual Circuit Connectivity Verification (VCCV) + trace mechanisms specified in [RFC6073], can be used by an operator + of the network to verify the path taken by the MS-PW and therefore be + satisfied that the path does not represent an additional security + risk. + + + + +Martini, et al. Standards Track [Page 18] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + Note that the PW control protocol may be used to establish and + maintain an MS-PW across administrative boundaries. Section 13 of + [RFC6073] specifies security considerations applicable to LDP used in + this manner, including considerations for establishing the integrity + of, and authenticating, LDP control messages. These considerations + also apply to the protocol extensions specified in this document. + + Note that the protocols for dynamically distributing AII reachability + information may have their own security considerations. However, + those protocol specifications are outside the scope of this document. + +8. IANA Considerations + +8.1. Correction + + IANA has corrected a minor error in the "Pseudowire Switching Point + PE sub-TLV Type" registry. The entry 0x06 "L2 PW address of the PW + Switching Point" has been corrected to Length 14 and the reference + changed to [RFC6073] and this document as follows: + + Type Length Description Reference + ---- ------ ----------------------------------- ------------------ + 0x06 14 L2 PW Address of PW Switching Point [RFC6073][RFC7267] + +8.2. LDP TLV Type Name Space + + This document defines one new LDP TLV type. IANA already maintains a + registry for LDP TLV types, called the "TLV Type Name Space" + registry, within the "Label Distribution Protocol (LDP) Parameters" + registry as defined by [RFC5036]. IANA has assigned the following + value. + + Value Description Reference Notes/Registration Date + ------ ------------- ------------- ----------------------- + 0x096E Bandwidth TLV This document + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 19] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +8.3. LDP Status Codes + + This document defines three new LDP status codes. IANA maintains a + registry of these codes, called the "Status Code Name Space" + registry, in the "Label Distribution Protocol (LDP) Parameters" + registry as defined by [RFC5036]. The IANA has assigned the + following values. + + Range/Value E Description Reference + ----------- ----- ------------------------------- ------------- + 0x00000037 0 Bandwidth resources unavailable This document + 0x00000038 0 Resources Unavailable This document + 0x00000039 0 AII Unreachable This document + +8.4. BGP SAFI + + IANA has allocated a new BGP SAFI for "Network Layer Reachability + Information used for Dynamic Placement of Multi-Segment Pseudowires" + in the IANA "SAFI Values" registry [RFC4760] within the "Subsequent + Address Family Identifiers (SAFI) Parameters" registry. The IANA has + assigned the following value. + + Value Description Reference + ----- ------------------------------------------- ------------- + 6 Network Layer Reachability Information This document + used for Dynamic Placement of Multi-Segment + Pseudowires + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated + Services", RFC 2210, September 1997. + + [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and + G. Heron, "Pseudowire Setup and Maintenance Using the + Label Distribution Protocol (LDP)", RFC 4447, April 2006. + + [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, + "Attachment Individual Identifier (AII) Types for + Aggregation", RFC 5003, September 2007. + + + + + + +Martini, et al. Standards Track [Page 20] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., + "LDP Specification", RFC 5036, October 2007. + + [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. + Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. + +9.2. Informative References + + [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast + Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, + May 2005. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + January 2006. + + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, + January 2007. + + [RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., + "Requirements for Multi-Segment Pseudowire Emulation Edge- + to-Edge (PWE3)", RFC 5254, October 2008. + + [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- + Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, + October 2009. + + [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, + "Provisioning, Auto-Discovery, and Signaling in Layer 2 + Virtual Private Networks (L2VPNs)", RFC 6074, + January 2011. + + [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., + Regan, J., and S. Amante, "Flow-Aware Transport of + Pseudowires over an MPLS Packet Switched Network", + RFC 6391, November 2011. + + [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire + Redundancy", RFC 6718, August 2012. + + + + + + + + + + + +Martini, et al. Standards Track [Page 21] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +10. Contributors + + The editors gratefully acknowledge the following people for their + contributions to this document: + + Nabil Bitar + Verizon + 40 Sylvan Road + Waltham, MA 02145 + US + + EMail: nabil.bitar@verizon.com + + + Himanshu Shah + Ciena Corp. + 35 Nagog Park + Acton, MA 01720 + US + + EMail: hshah@ciena.com + + + Mustapha Aissaoui + Alcatel-Lucent + 600 March Road + Kanata + ON, Canada + + EMail: mustapha.aissaoui@alcatel-lucent.com + + + Jason Rusmisel + Alcatel-Lucent + 600 March Road + Kanata + ON, Canada + + EMail: Jason.rusmisel@alcatel-lucent.com + + + Andrew G. Malis + Huawei + 2330 Central Expressway + Santa Clara, CA 95050 + US + + EMail: agmalis@gmail.com + + + +Martini, et al. Standards Track [Page 22] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + + Chris Metz + Cisco Systems, Inc. + 3700 Cisco Way + San Jose, CA 95134 + US + + EMail: chmetz@cisco.com + + + David McDysan + Verizon + 22001 Loudoun County Pkwy. + Ashburn, VA 20147 + US + + EMail: dave.mcdysan@verizon.com + + + Jeff Sugimoto + Alcatel-Lucent + 701 E. Middlefield Rd. + Mountain View, CA 94043 + US + + EMail: jeffery.sugimoto@alcatel-lucent.com + + + Mike Loomis + Alcatel-Lucent + 701 E. Middlefield Rd. + Mountain View, CA 94043 + US + + EMail: mike.loomis@alcatel-lucent.com + +11. Acknowledgements + + The editors also gratefully acknowledge the input of the following + people: Paul Doolan, Mike Duckett, Pranjal Dutta, Ping Pan, Prayson + Pate, Vasile Radoaca, Yeongil Seo, Yetik Serbest, and Yuichiro Wada. + + + + + + + + + + + +Martini, et al. Standards Track [Page 23] + +RFC 7267 Dynamic Placement of Multi-Segment PWs June 2014 + + +Authors' Addresses + + Luca Martini (editor) + Cisco Systems, Inc. + 9155 East Nichols Avenue, Suite 400 + Englewood, CO 80112 + US + + EMail: lmartini@cisco.com + + + Matthew Bocci (editor) + Alcatel-Lucent + Voyager Place + Shoppenhangers Road + Maidenhead + Berks, UK + + EMail: matthew.bocci@alcatel-lucent.com + + + Florin Balus (editor) + Alcatel-Lucent + 701 E. Middlefield Rd. + Mountain View, CA 94043 + US + + EMail: florin@nuagenetworks.net + + + + + + + + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 24] + |