diff options
Diffstat (limited to 'doc/rfc/rfc8338.txt')
| -rw-r--r-- | doc/rfc/rfc8338.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc8338.txt b/doc/rfc/rfc8338.txt new file mode 100644 index 0000000..9d247eb --- /dev/null +++ b/doc/rfc/rfc8338.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Boutros, Ed. +Request for Comments: 8338 VMware +Updates: 7385 S. Sivabalan, Ed. +Category: Standards Track Cisco Systems +ISSN: 2070-1721 March 2018 + + + Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP + +Abstract + + This document specifies a mechanism to signal Point-to-Multipoint + (P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable + for any Layer 2 VPN service requiring P2MP connectivity over an IP or + MPLS-enabled PSN. A P2MP PW established via the proposed mechanism + is root initiated. This document updates RFC 7385 by reassigning the + reserved value 0xFF to be the wildcard transport tunnel type. + +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 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8338. + +Copyright Notice + + Copyright (c) 2018 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 + (https://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. + + + + + +Boutros & Sivabalan Standards Track [Page 1] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. PW Ingress-to-Egress Incompatibility Issues . . . . . . . 6 + 3.2. P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2.1. P2MP PW Upstream FEC Element . . . . . . . . . . . . 7 + 3.2.2. P2P PW Downstream FEC Element . . . . . . . . . . . . 11 + 3.3. Typed Wildcard FEC Format for a New FEC . . . . . . . . . 11 + 3.4. Group ID Usage . . . . . . . . . . . . . . . . . . . . . 12 + 3.5. Generic Label TLV . . . . . . . . . . . . . . . . . . . . 12 + 4. LDP Capability Negotiation . . . . . . . . . . . . . . . . . 12 + 5. P2MP PW Status . . . . . . . . . . . . . . . . . . . . . . . 14 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 7.1. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 15 + 7.2. LDP TLV Type . . . . . . . . . . . . . . . . . . . . . . 15 + 7.3. mLDP Opaque Value Element TLV Type . . . . . . . . . . . 15 + 7.4. Selective Tree Interface Parameter Sub-TLV Type . . . . . 15 + 7.5. Wildcard PMSI Tunnel Type . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 8.2. Informative References . . . . . . . . . . . . . . . . . 17 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + +1. Introduction + + A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential + attributes of a unidirectional P2MP Telecommunications service such + as P2MP ATM over PSN. A major difference between a Point-to-Point + (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is + intended for bidirectional service whereas the latter is intended for + both unidirectional and, optionally, bidirectional service. + Requirements for P2MP PWs are described in [RFC7338]. P2MP PWs can + be constructed as either Single Segment Pseudowires (P2MP SS-PWs) or + Multi-Segment Pseudowires (P2MP MS-PWs) as mentioned in [RFC7338]. + P2MP MS-PW is outside the scope of this document. A reference model + or a P2MP PW is depicted in Figure 1. A transport Label Switched + Path (LSP) associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP + (i.e., P2MP Traffic Engineering (TE) tunnel established via RSVP-TE + [RFC4875] or P2MP LSP established via Multipoint LDP (mLDP) + [RFC6388]) spanning from the Root PE (Provider Edge) to the Leaf + + + + +Boutros & Sivabalan Standards Track [Page 2] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + PE(s) of the P2MP SS-PW tree. For example, in Figure 1, PW1 can be + associated with a P2MP TE tunnel or P2MP LSP setup using mLDP + originating from PE1 and terminating at PE2, PE3, and PE4. + + |<--------------P2MP PW---------------->| + Native | | Native + Service | |<--PSN1->| |<--PSN2->| | Service + (AC) V V V V V V (AC) + | +-----+ +------+ +------+ | + | | | | P1 |=========|T-PE2 |AC3 | +---+ + | | | | .......PW1.........>|-------->|CE3| + | |T-PE1|=========| . |=========| | | +---+ + | | .......PW1........ | +------+ | + | | . |=========| . | +------+ | + | | . | | . |=========|T-PE3 |AC4 | +---+ + +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| + |CE1|------->|... | | |=========| | | +---+ + +---+ | | . | +------+ +------+ | + | | . | +------+ +------+ | + | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ + | | .......PW1..............PW1.........>|-------->|CE5| + | | |=========| |=========| | | +---+ + | +-----+ +------+ +------+ | + + Figure 1: P2MP PW + + Mechanisms for establishing a P2P SS-PW using LDP are described in + [RFC8077]. This document specifies a method of signaling P2MP PW + using LDP. In particular, this document defines a new Forwarding + Equivalence Class (FEC), TLVs, parameters, and status codes to + facilitate LDP signaling and maintaining P2MP PWs. + + As outlined in [RFC7338], even though the traffic flow from a Root PE + (R-PE) to Leaf PE(s) (L-PEs) is P2MP in nature, it may be desirable + for any L-PE to send unidirectional P2P traffic destined only to the + R-PE. The proposed mechanism takes such an option into + consideration. + + The P2MP PW requires an MPLS LSP to carry the PW traffic, and the + MPLS packets carrying the PW upstream label will be encapsulated + according to the methods described in [RFC5332]. + + + + + + + + + + +Boutros & Sivabalan Standards Track [Page 3] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + +2. Terminology + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2.2. Abbreviations + + AGI: Attachment Group Identifier + + CE: Customer Edge + + FEC: Forwarding Equivalence Class + + L-PE: Leaf PE (egress PE) + + LDP: Label Distribution Protocol + + LSP: Label Switched Path + + mLDP: Multipoint Label Distribution Protocol (for P2MP/MP2MP LSP) + + MS-PW: Multi-Segment Pseudowire + + P2MP: Point-to-Multipoint + + P2P: Point-to-Point + + PE: Provider Edge + + PSN: Packet Switched Network + + PW: Pseudowire + + R-PE: Root PE (ingress PE, PE initiating P2MP PW setup) + + S-PE: Switching Provider Edge (of MS-PW) + + SS-PW: Single-Segment Pseudowire + + TE: Traffic Engineering + + + + + + +Boutros & Sivabalan Standards Track [Page 4] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + +3. Signaling P2MP PW + + In order to advertise labels as well as exchange PW-related LDP + messages, PEs must establish LDP sessions among themselves. A PE + discovers other PEs that are to be connected via P2MP PWs either via + manual configuration or autodiscovery [RFC6074]. + + An R-PE and each L-PE MUST be configured with the same FEC as defined + in Section 3.2. + + P2MP PW requires that there be an active P2MP PSN LSP set up between + an R-PE and L-PE(s). Note that the procedure to set up the P2MP PSN + LSP is different depending on the signaling protocol used (RSVP-TE or + mLDP). + + In the case of mLDP, a Leaf PE can decide to join the P2MP LSP at any + time. In the case of RSVP-TE, the P2MP LSP is set up by the R-PE, + generally at the initial service provisioning time. It should be + noted that local policy can override any decision to join, add, or + prune existing or new L-PEs from the tree. In any case, the PW setup + can ignore these differences and simply assume that the P2MP PSN LSP + is available when needed. + + P2MP PW signaling is initiated by the R-PE, which sends a separate + P2MP PW LDP Label Mapping Message to each of the L-PE(s) belonging to + that P2MP PW. This Label Mapping Message will contain the following: + + 1. A FEC TLV containing a P2MP PW Upstream FEC Element that includes + a Transport LSP sub-TLV. + + 2. An Interface Parameters TLV, as described in [RFC8077]. + + 3. A PW Group ID TLV, as described in [RFC8077]. + + 4. A label TLV for the upstream-assigned label used by an R-PE for + the traffic going from the R-PE to L-PE(s). + + The R-PE imposes the upstream-assigned PW label on the outbound + packets sent over the P2MP PW; using this label, an L-PE identifies + the inbound packets arriving over the P2MP PW. + + + + + + + + + + + +Boutros & Sivabalan Standards Track [Page 5] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + Additionally, the R-PE MAY send Label Mapping Messages to one or more + L-PEs to signal a unidirectional P2P PW(s). The L-PE(s) can use such + a PW(s) to send traffic to the R-PE. This optional Label Mapping + Message will contain the following: + + 1. A P2P PW Downstream FEC Element + + 2. A label TLV for the downstream-assigned label used by the + corresponding L-PE to send traffic to the R-PE + + The LDP liberal label retention mode MUST be used; per requirements + specified in [RFC5036], the Label Request message MUST also be + supported. + + The upstream-assigned label is allocated according to the rules in + [RFC5331]. + + When an L-PE receives a PW Label Mapping Message, it MUST verify the + associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP + is not in place and its type is LDP P2MP LSP, the L-PE MUST attempt + to join the P2MP LSP associated with the P2MP PW. If the associated + P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP LSP, the + L-PE SHOULD wait till the P2MP transport LSP is signaled. If an L-PE + fails to join the P2MP PSN LSP, that L-PE MUST not enable the PW and + MUST notify the user. In this case, a PW status message with status + code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault) MUST + also be sent to the R-PE. + +3.1. PW Ingress-to-Egress Incompatibility Issues + + If an R-PE signals a PW with a PW Type, Control Word (CW) mode, or + interface parameters that a particular L-PE cannot accept, then the + L-PE MUST NOT enable the PW and should notify the user. In this + case, a PW status message with status code of 0x00000001 (Pseudowire + Not Forwarding) MUST also be sent to the R-PE. + + Note that this procedure does not apply if the L-PE was not + provisioned with this particular P2MP PW. In this case, according to + the LDP liberal label retention rules, no action is taken. + +3.2. P2MP PW FEC + + [RFC8077] specifies two types of LDP FEC elements used to signal P2P + PWs: "PWid FEC Element" and "Generalized PWid FEC Element". This + document uses two FEC elements: "P2MP PW Upstream FEC Element" and + "P2P PW Downstream FEC Element". These FEC elements are associated + with a mandatory upstream-assigned label and an optional downstream- + assigned label, respectively. + + + +Boutros & Sivabalan Standards Track [Page 6] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + +3.2.1. P2MP PW Upstream FEC Element + + The FEC type for the P2MP PW Upstream FEC Element is encoded 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |P2MP PW Up=0x82|C| PW Type | PW Info Length| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AGI Type | AGI Length | AGI Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ AGI Value (contd.) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AII Type | SAII Length | SAII Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ SAII Value (contd.) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |PMSI Tunnel Typ|PMSI TT Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + ~ Transport LSP ID ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Optional Parameters | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: P2MP PW Upstream FEC Element + + * P2MP PW Up: + + 8-bit representation for the P2MP PW Upstream FEC type. + + * C bit: + + A value of 1 or 0 indicating whether a control word is present or + absent for the P2MP PW. + + * PW Type: + + 15-bit representation of PW Type as specified in [RFC8077]. + + + + + + +Boutros & Sivabalan Standards Track [Page 7] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + * PW Info Length: + + Sum of the AGI Length, SAII Length, PMSI Tunnel Type Length, and + Optional Parameters fields in octets. If this value is 0, then it + references all PWs using the specified group ID. In this case, + there are neither other FEC element fields (AGI Type, SAII Value, + etc.) present, nor any interface parameters TLVs. Alternatively, + typed wildcard FEC described in Section 2.3, can be used to + achieve the same or to have better filtering. + + * AGI: + + An Attachment Group Identifier TLV can be used to uniquely + identify a VPN or Virtual Private LAN Service (VPLS) instance + associated with the P2MP PW. This has the same format as the + Generalized PWid FEC Element [RFC8077]. + + * SAII Value: + + A Source Attachment Individual Identifier is used to identify the + root of the P2MP PW. The root is represented using AII Type 2 + format specified in [RFC5003]. Note that the SAII can be omitted + by simply setting the length and type to zero. + + The P2MP PW is identified by the Source Attachment Identifier + (SAI). If the AGI is non-null, the SAI is the combination of the + SAII and the AGI, if the AGI is null, the SAI is the SAII. + + * PMSI Tunnel Info: + + The PMSI Tunnel Info is the combination of the PMSI Tunnel Type, + PMSI Tunnel Type Length (shown in the figure as PMSI TT Length), + and Transport LSP ID fields. + + A P2MP PW MUST be associated with a transport LSP, which can be + established using RSVP-TE or mLDP. + + * PMSI Tunnel Type: + + The PMSI Tunnel Type is defined in [RFC6514]. + + When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a + P2MP FEC Element as defined in [RFC6388]. The new mLDP Opaque + Value Element type for the L2VPN-MCAST application TLV (as + specified in the IANA Considerations section (Section 7)) MUST be + used. + + + + + +Boutros & Sivabalan Standards Track [Page 8] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + * Transport LSP ID: + + This is the Tunnel Identifier that is defined in [RFC6514]. + + An R-PE sends a Label Mapping Message as soon as the transport LSP + ID associated with the P2MP PW is known (e.g., via configuration) + regardless of the operational state of that transport LSP. + + Similarly, an R-PE does not withdraw the labels when the + corresponding transport LSP goes down. Furthermore, an L-PE + retains the P2MP PW labels regardless of the operational status of + the transport LSP. + + Note that a given transport LSP can be associated with more than + one P2MP PW; in which case, P2MP PWs will be sharing the same R-PE + and L-PE(s). An R-PE may also have many P2MP PWs with disjoint + L-PE sets. + + In the case of LDP P2MP LSP, when an L-PE receives the Label + Mapping Message, it can initiate the process of joining the P2MP + LSP tree associated with the P2MP PW. + + In the case of RSVP-TE P2MP LSP, only the R-PE initiates the + signaling of P2MP LSP. + + * Optional Parameters: + + The Optional Parameter field can contain some TLVs that are not + part of the FEC, but are necessary for the operation of the PW. + This proposed mechanism uses two such TLVs: the Interface + Parameters TLV and the PW Group ID TLV. + + The Interface Parameters TLV and PW Group ID TLV specified in + [RFC8077] can also be used in conjunction with P2MP PW FEC in a + label message. For the PW Group ID TLV, the sender and receiver + of these TLVs should follow the same rules and procedures + specified in [RFC8077]. For the Interface Parameters TLV, the + procedure differs from the one specified in [RFC8077] due to + specifics of P2MP connectivity. When the interface parameters are + signaled by an R-PE, each L-PE must check if its configured + value(s) is less than or equal to the threshold value provided by + the R-PE (e.g., MTU size (Ethernet), max number of concatenated + ATM cells, etc.). For other interface parameters, like CEP/TDM + Payload Bytes, the value MUST exactly match the values signaled by + the R-PE. + + + + + + +Boutros & Sivabalan Standards Track [Page 9] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + A multicast traffic stream associated with a P2MP PW can be + selective or inclusive. To support the former, this document + defines a new optional Selective Tree Interface Parameter sub-TLV, + as described in the IANA Considerations section (Section 7) and + according to the format described in [RFC8077]. The value of the + sub-TLV contains the source and the group for a given multicast + tree, as shown in Figure 3. Also, if a P2MP PW is associated with + multiple selective trees, the corresponding Label Mapping Message + will carry more than one instance of this sub-TLV. Furthermore, + in the absence of this sub-TLV, the P2MP PW is associated with all + multicast traffic streams originating from the root. + + +-----------------------------------------+ + | Sub-TLV Type (1 Octet) | + +-----------------------------------------+ + | Length (1 Octet) | + +-----------------------------------------+ + | Multicast Source Length (1 Octet) | + +-----------------------------------------+ + | Multicast Source (variable length) | + +-----------------------------------------+ + | Multicast Group Length (1 Octet) | + +-----------------------------------------+ + | Multicast Group (variable length) | + +-----------------------------------------+ + + Figure 3: Selective Tree Interface Parameter Sub-TLV Value + + Note that since the LDP Label Mapping Message is only sent by the + R-PE to all the L-PEs, it is not possible to negotiate any + interface parameters. + + + + + + + + + + + + + + + + + + + + +Boutros & Sivabalan Standards Track [Page 10] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + +3.2.2. P2P PW Downstream FEC Element + + The optional P2P PW Downstream FEC Element is encoded 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |P2P PWDown=0x84|C| PW Type | PW Info Length| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AGI Type | Length | AGI Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ AGI Value (contd.) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AII Type | Length | SAII Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ SAII Value (contd.) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: P2P PW Downstream FEC Element + + The definition of the fields in the P2P PW Downstream FEC Element is + the same as those of P2MP PW Upstream FEC Element, shown in Figure 2. + +3.3. Typed Wildcard FEC Format for a New FEC + + [RFC5918] defines the general notion of a Typed Wildcard FEC Element; + it requires FEC designers to specify a Typed Wildcard FEC Element for + newly defined FEC element types. This document uses two FEC + elements: "P2MP PW Upstream" and "P2P PW Downstream". Hence, + definition of their Typed Wildcard format is required. + + [RFC6667] defines the Typed Wildcard FEC Element format for other PW + FEC Element types (PWid and Generalized PWid FEC Element) in + Section 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Typed Wcard=0x5|Type=PW FEC | Len = 3 |R| PW Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | . . . | PMSI Tun Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Typed Wildcard Format for P2MP PW FEC Elements + + + + + +Boutros & Sivabalan Standards Track [Page 11] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + [RFC6667] specifies that the Type field can be either the "PWid" + (0x80) or "Generalized PWid" (0x81) FEC Element type. This document + reuses the existing Typed Wildcard format specified in [RFC6667] and + illustrated in Figure 5 and extends the definition of the Type field + to also include the P2MP PW Upstream FEC Element and P2P PW + Downstream FEC Element types. This document adds an additional field + called the "PMSI Tunnel Type". This document reserves PMSI Tunnel + Type 0xFF to mean "wildcard transport tunnel type". The PMSI Tunnel + Type field only applies to the Typed Wildcard P2MP PW Upstream FEC + Element and MUST be set to "wildcard" for "P2P PW Downstream FEC + Element" typed wildcard. + +3.4. Group ID Usage + + The PW Group ID TLV as defined in [RFC8077] contains a group ID + capable of indicating an arbitrary group membership of a P2MP PW. + This group ID can be used in LDP "wildcard" status and withdraw label + messages, as described in [RFC8077]. + +3.5. Generic Label TLV + + As in the case of P2P PW signaling, P2MP PW labels are carried within + the Generic Label TLV contained in the LDP Label Mapping Message. A + Generic Label TLV is formatted and processed as per the rules and + procedures specified in [RFC8077]. For a given P2MP PW, a single + upstream-assigned label is allocated by the R-PE and is advertised to + all L-PEs using the Generic Label TLV in Label Mapping Messages + containing the P2MP PW Upstream FEC Element. + + The R-PE can also allocate a unique label for each L-PE from which it + intends to receive P2P traffic. Such a label is advertised to the + L-PE using the Generic Label TLV and P2P PW Downstream FEC Element in + Label Mapping Messages. + +4. LDP Capability Negotiation + + The capability of supporting P2MP PWs MUST be advertised to all LDP + peers. This is achieved by using the methods in [RFC5561] to + advertise the LDP P2MP PW Capability TLV. If an LDP peer supports + the dynamic capability advertisement, this can be done by sending a + new Capability message with the S bit set for the P2MP PW Capability + TLV. If the peer does not support dynamic capability advertisement, + then the P2MP PW Capability TLV MUST be included in the LDP + Initialization message during session establishment. A Label + Switched Router (LSR) having P2MP PW capability MUST recognize both + the P2MP PW Upstream FEC Element and P2P PW Downstream FEC Element in + LDP label messages. + + + + +Boutros & Sivabalan Standards Track [Page 12] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + In line with requirements listed in [RFC5561], the following TLV is + defined to indicate the P2MP PW capability: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|F| P2MP PW Capability TLV | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| Reserved | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: LDP P2MP PW Capability TLV + + * U bit: + + The Unknown bit [RFC5036] SHOULD be 1 (ignore if not understood). + + * F bit: + + The Forward unknown bit [RFC5036] SHOULD be 0 (don't forward if + not understood). + + * P2MP PW Capability TLV Code Point: + + The TLV type, which identifies a specific capability. Note that + the P2MP PW Capability Code Point appears in the IANA + Considerations section (Section 7). + + * S bit: + + The State Bit indicates whether the sender is advertising or + withdrawing the P2MP PW capability. The State bit is used as + follows: + + 1 - The TLV is advertising the capability specified by the P2MP PW + Capability TLV Code Point. + + 0 - The TLV is withdrawing the capability specified by the P2MP PW + Capability TLV Code Point. + + * Length: + + MUST be set to 2 (octet). + + + + + + + + +Boutros & Sivabalan Standards Track [Page 13] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + +5. P2MP PW Status + + In order to support the proposed mechanism, an LSR MUST be capable of + handling PW status. As such, the PW status negotiation procedures + described in [RFC8077] are not applicable to P2MP PW. An LSR MUST + NOT claim to be P2MP PW capable by sending an LDP P2MP PW Capability + TLV if it is not also capable of handling PW status. + + Once an L-PE successfully processes a Label Mapping Message for a + P2MP PW, it MUST send appropriate PW status according to the + procedure specified [RFC8077] to report the PW status. If no PW + status notification is required, then no PW status notification is + sent (for example, if the P2MP PW is established and operational with + a status code of 0x00000000 (Success), a PW status message is not + necessary). A PW status message sent from an L-PE to an R-PE MUST + contain the P2P PW Downstream FEC Element to identify the PW. + + An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP + PW state. Such a PW status message contains a P2MP PW Upstream FEC + Element to identify the PW. + + Connectivity status of the underlying P2MP LSP that the P2MP PW is + associated with can be verified using LSP ping and traceroute + procedures described in [RFC6425]. + +6. Security Considerations + + In general, the security measures described in [RFC8077] are adequate + for this protocol. However, the use of MD5 as the method of securing + an LDP control plane is no longer considered adequately secure. + Implementations should be written in such a way that they can migrate + to a more secure cryptographic hash function when the next + authentication method to be used in the LDP might not be a simple + hash-based authentication algorithm. + +7. IANA Considerations + +7.1. FEC Type Name Space + + This document uses two FEC element types, 0x82 and 0x84, in the + "Forwarding Equivalence Class (FEC) Type Name Space" registry for the + Label Distribution Protocol (LDP) [RFC5036]. IANA has added this + document as a reference for the following entries: + + Value Hex Name Reference + ------ ----- ----------------------------- -------------------- + 130 0x82 P2MP PW Upstream FEC Element [RFC8338] [RFC7358] + 132 0x84 P2P PW Downstream FEC Element [RFC8338] [RFC7358] + + + +Boutros & Sivabalan Standards Track [Page 14] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + +7.2. LDP TLV Type + + This document defines a new LDP TLV type in the "TLV Type Name Space" + registry [RFC5036]. IANA has assigned the following value: + + TLV Type Description + -------- ---------------------- + 0x0703 P2MP PW Capability TLV + +7.3. mLDP Opaque Value Element TLV Type + + IANA has assigned a new mLDP Opaque Value Element Type in the "LDP MP + Opaque Value Element basic type" registry [RFC6388] as follows: + + TLV Type Description + ------- --------------------------- + 13 L2VPN-MCAST application TLV + + Length: 4 + + Value: A 32-bit integer, unique in the context of the + root, as identified by the root's address. + +7.4. Selective Tree Interface Parameter Sub-TLV Type + + IANA has assigned a sub-TLV from the "Pseudowire Interface Parameters + Sub-TLV type Registry" [RFC4446] as follows: + + TLV Type Description + -------- ---------------------------------- + 0x1B Selective Tree Interface Parameter + +7.5. Wildcard PMSI Tunnel Type + + IANA has modified an entry in the "P-Multicast Service Interface + Tunnel (PMSI Tunnel) Tunnel Types" registry within the "Border + Gateway Protocol (BGP) Parameters" registry [RFC7385]. Value 0xFF, + which was previously marked as "Reserved", has been updated as + follows: + + Value Meaning Reference + ----- ------------------------------ --------- + 0xFF wildcard transport tunnel type [RFC8338] + + + + + + + + +Boutros & Sivabalan Standards Track [Page 15] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge + Emulation (PWE3)", BCP 116, RFC 4446, + DOI 10.17487/RFC4446, April 2006, + <https://www.rfc-editor.org/info/rfc4446>. + + [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. + Yasukawa, Ed., "Extensions to Resource Reservation + Protocol - Traffic Engineering (RSVP-TE) for Point-to- + Multipoint TE Label Switched Paths (LSPs)", RFC 4875, + DOI 10.17487/RFC4875, May 2007, + <https://www.rfc-editor.org/info/rfc4875>. + + [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, + "Attachment Individual Identifier (AII) Types for + Aggregation", RFC 5003, DOI 10.17487/RFC5003, September + 2007, <https://www.rfc-editor.org/info/rfc5003>. + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., + "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, + October 2007, <https://www.rfc-editor.org/info/rfc5036>. + + [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream + Label Assignment and Context-Specific Label Space", + RFC 5331, DOI 10.17487/RFC5331, August 2008, + <https://www.rfc-editor.org/info/rfc5331>. + + [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, + "MPLS Multicast Encapsulations", RFC 5332, + DOI 10.17487/RFC5332, August 2008, + <https://www.rfc-editor.org/info/rfc5332>. + + [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. + Le Roux, "LDP Capabilities", RFC 5561, + DOI 10.17487/RFC5561, July 2009, + <https://www.rfc-editor.org/info/rfc5561>. + + + + + + + +Boutros & Sivabalan Standards Track [Page 16] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution + Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class + (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, + <https://www.rfc-editor.org/info/rfc5918>. + + [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. + Thomas, "Label Distribution Protocol Extensions for Point- + to-Multipoint and Multipoint-to-Multipoint Label Switched + Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, + <https://www.rfc-editor.org/info/rfc6388>. + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, + <https://www.rfc-editor.org/info/rfc6514>. + + [RFC6667] Raza, K., Boutros, S., and C. Pignataro, "LDP 'Typed + Wildcard' Forwarding Equivalence Class (FEC) for PWid and + Generalized PWid FEC Elements", RFC 6667, + DOI 10.17487/RFC6667, July 2012, + <https://www.rfc-editor.org/info/rfc6667>. + + [RFC7385] Andersson, L. and G. Swallow, "IANA Registry for + P-Multicast Service Interface (PMSI) Tunnel Type Code + Points", RFC 7385, DOI 10.17487/RFC7385, October 2014, + <https://www.rfc-editor.org/info/rfc7385>. + + [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and + Maintenance Using the Label Distribution Protocol (LDP)", + STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, + <https://www.rfc-editor.org/info/rfc8077>. + + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +8.2. Informative References + + [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation + Edge-to-Edge (PWE3) Architecture", RFC 3985, + DOI 10.17487/RFC3985, March 2005, + <https://www.rfc-editor.org/info/rfc3985>. + + + + + + + + +Boutros & Sivabalan Standards Track [Page 17] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, + "Provisioning, Auto-Discovery, and Signaling in Layer 2 + Virtual Private Networks (L2VPNs)", RFC 6074, + DOI 10.17487/RFC6074, January 2011, + <https://www.rfc-editor.org/info/rfc6074>. + + + [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., + Yasukawa, S., and T. Nadeau, "Detecting Data-Plane + Failures in Point-to-Multipoint MPLS - Extensions to LSP + Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, + <https://www.rfc-editor.org/info/rfc6425>. + + + [RFC7338] Jounay, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci, + "Requirements and Framework for Point-to-Multipoint + Pseudowires over MPLS Packet Switched Networks", RFC 7338, + DOI 10.17487/RFC7338, September 2014, + <https://www.rfc-editor.org/info/rfc7338>. + + [RFC7358] Raza, K., Boutros, S., Martini, L., and N. Leymann, "Label + Advertisement Discipline for LDP Forwarding Equivalence + Classes (FECs)", RFC 7358, DOI 10.17487/RFC7358, October + 2014, <https://www.rfc-editor.org/info/rfc7358>. + +Acknowledgments + + The authors would like to thank Andre Pelletier and Parag Jain for + their valuable suggestions. + +Contributors + + The following people contributed substantially to the content of this + document and should be considered coauthors: + + Luca Martini + Cisco Systems, Inc. + + Email: lmartini@cisco.com + + Maciek Konstantynowicz + Cisco Systems, Inc. + + Email: maciek@cisco.com + + + + + + + +Boutros & Sivabalan Standards Track [Page 18] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + + Gianni Del Vecchio + Swisscom + + Email: Gianni.DelVecchio@swisscom.com + + Thomas D. Nadeau + Brocade + + Email: tnadeau@lucidvision.com + + Frederic Jounay + Orange CH + + Email: Frederic.Jounay@salt.ch + + Philippe Niger + Orange CH + + Email: philippe.niger@orange.com + + Yuji Kamite + NTT Communications Corporation + + Email: y.kamite@ntt.com + + Lizhong Jin + + Email: lizho.jin@gmail.com + + Martin Vigoureux + Nokia + + Email: martin.vigoureux@nokia.com + + Laurent Ciavaglia + Nokia + + Email: laurent.ciavaglia@nokia.com + + Simon Delord + Telstra + + Email: simon.delord@gmail.com + + Kamran Raza + Cisco Systems + + Email: skraza@cisco.com + + + +Boutros & Sivabalan Standards Track [Page 19] + +RFC 8338 Root-Initiated P2MP Pseudowire March 2018 + + +Authors' Addresses + + Sami Boutros (editor) + VMware, Inc. + + Email: sboutros@vmware.com + + + Siva Sivabalan (editor) + Cisco Systems, Inc. + + Email: msiva@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Boutros & Sivabalan Standards Track [Page 20] + |