idnits 2.17.00 (12 Aug 2021) /tmp/idnits41596/draft-ietf-pwe3-p2mp-pw-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 26, 2010) is 4316 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: draft-ietf-l3vpn-2547bis-mcast-bgp has been published as RFC 6514 == Outdated reference: draft-ietf-l2vpn-signaling has been published as RFC 6074 == Outdated reference: draft-ietf-pwe3-p2mp-pw-requirements has been published as RFC 7338 == Outdated reference: draft-ietf-mpls-p2mp-lsp-ping has been published as RFC 6425 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Luca Martini 3 Internet Draft Sami Boutros 4 Expiration Date: January 2011 Siva Sivabalan 5 Intended status: Standards Track Cisco 7 Maciek Konstantynowicz 8 Juniper 10 Frederic Jounay Gianni Del Vecchio 11 Philippe Niger Swisscom 12 France Telecom 14 Thomas D. Nadeau Yuji Kamite 15 BT NTT Communications 17 Simon Delord Lizhong Jin 18 Telstra ZTE 20 Laurent Ciavaglia 21 Martin Vigoureux 22 Alcatel-Lucent 23 July 26, 2010 25 Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP 27 draft-ietf-pwe3-p2mp-pw-00.txt 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on January 26, 2010 52 Abstract 54 This document specifies a mechanism to signal Point-to-Multipoint 55 (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable 56 for any Layer 2 VPN service requiring P2MP connectivity over an IP or 57 MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is 58 root initiated. 60 Table of Contents 62 1 Specification of Requirements ........................ 3 63 2 Introduction ......................................... 3 64 3 Terminology .......................................... 4 65 4 Signaling the P2MP PW ................................ 5 66 4.1 PW ingress to egress incompatibility issues .......... 6 67 4.2 P2MP PW FEC Element .................................. 7 68 4.3 Group ID usage ....................................... 9 69 4.4 Generic Label TLV .................................... 9 70 4.5 Transport LSP TLV .................................... 10 71 5 LDP Capability Negotiation ........................... 12 72 6 P2MP PW status ....................................... 13 73 7 Security Considerations .............................. 13 74 8 IANA Considerations .................................. 13 75 8.1 FEC Type Name Space .................................. 13 76 8.2 LDP TLV TYPE ......................................... 14 77 9 References ........................................... 14 78 9.1 Normative References ................................. 14 79 9.2 Informative References ............................... 15 80 10 Author's Addresses ................................... 15 82 1. Specification of Requirements 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Introduction 90 A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential 91 attributes of a unidirectional P2MP Telecommunications service such 92 as P2MP ATM over PSN. A major difference between a Point-to-Point 93 (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is 94 intended for bidirectional service whereas the latter is intended for 95 both unidirectional, or optionally bidirectional service. 96 Requirements for P2MP PW are described in [P2MP-PW-REQ]. 98 P2MP PW can be constructed as either Single Segment (P2MP SS-PW) or 99 Multi Segment (P2MP MS-PW) Pseudowires as mentioned in [P2MP-PW-REQ]. 100 P2MP MS-PW is outside the scope of this document. A reference model 101 for P2MP PW is depicted in Figure 1 below. A transport LSP associated 102 with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel 103 established via RSVP-TE [RFC4875] or P2MP LSP established via mLDP 104 [mLDP]) spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW 105 tree. For example, in Figure 1, PW1 can be associated with a P2MP TE 106 tunnel or P2MP LSP setup using [mLDP] originating from PE1 and 107 terminating at PE2 and PE3. 109 |<--------------P2MP PW---------------->| 110 Native | | Native 111 Service | |<--PSN1->| |<--PSN2->| | Service 112 (AC) V V V V V V (AC) 113 | +-----+ +------+ +------+ | 114 | | | | P1 |=========|T-PE2 |AC3 | +---+ 115 | | | | .......PW1.........>|-------->|CE3| 116 | |T-PE1|=========| . |=========| | | +---+ 117 | | .......PW1........ | +------+ | 118 | | . |=========| . | +------+ | 119 | | . | | . |=========|T-PE3 |AC4 | +---+ 120 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 121 |CE1|------->|... | | |=========| | | +---+ 122 +---+ | | . | +------+ +------+ | 123 | | . | +------+ +------+ | 124 | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ 125 | | .......PW1..............PW1.........>|-------->|CE5| 126 | | |=========| |=========| | | +---+ 127 | +-----+ +------+ +------+ | 129 Figure 1: P2MP PW 131 Mechanisms for establishing P2P SS-PW using LDP are described in 132 [RFC4447]. In this document, we specify a method to signal P2MP PW 133 using LDP. In particular, we define new TLVs, parameters, and status 134 codes to facilitate LDP to signal and maintain P2MP PWs. 136 Note that even though the traffic flow from a Root-PE to Leaf-PE(s) 137 is P2MP in nature, it may be desirable for any Leaf-PE to send 138 unidirectional P2P traffic destined only to the Root-PE. The proposed 139 mechanism takes such an option into consideration. 141 The P2MP PW requires an MPLS LSP to carry the PW traffic. the PW MPLS 142 packet will be encapsulated according to the methods described in 143 [RFC5332]. 145 3. Terminology 147 FEC: Forwarding Equivance Class 149 LDP: Label Distribution Protocol 151 mLDP: Label Distribution Protocol for P2MP LSP 153 LSP: Label Switching Path 154 MS-PW: Multi-Segment Pseudowire 156 P2P: Point to Point 158 P2MP: Point to Multipoint 160 PE: Provider Edge 162 PSN: Packet Switched Network 164 PW: Pseudowire 166 SS-PW: Single-Segment Pseudowire 168 S-PE: Switching Provider Edge Node of MS-PW 170 TE: Traffic Engineering 172 R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. 174 L-PE: Leaf-PE - egress PE. 176 4. Signaling the P2MP PW 178 In order to advertise labels as well as exchange PW related LDP 179 messages, PEs must establish LDP sessions among themselves using the 180 Extended Discovery Mechanisms. A PE discovers other PEs that are to 181 be connected via P2MP PWs either via manual configuration or 182 autodiscovery [BGP-AD]. 184 Root-PE and each Leaf-PE MUST be configured with the same FEC as 185 defined in the following section. 187 P2MP PW requires that there is an active P2MP PSN LSP set up between 188 Root-PE and Leaf-PE(s). Note that the procedure to set up the P2MP 189 PSN LSP is different depending on the protocol used: RSVP-TE or mLDP. 191 In case of mLDP a Leaf-PE can decide to join the P2MP LSP at any 192 time, while in case of RSVP-TE the P2MP LSP is set up by the Root-PE, 193 generally at the initial service provisioning time. It should be 194 noted that local policy can override any decision to join, add or 195 prune existing or new Leaf-PE(s) from the tree. 197 In any case the PW setup can ignore these differences, and simply 198 assume that the P2MP tunnel is available when needed. 200 The P2MP PW is initiated by the root (source) Provider Edge router 201 (R-PE), by simply sending an P2MP-PW LDP label mapping message to all 202 the Leaf Provider Edge routers L-PEs. This label mapping message will 203 contain the following: 204 -i. P2MP PW FEC element. 205 -ii. an Interface Parameters TLV, as described in [RFC4447] sec 206 5.3.2.1 207 -iii. a PW Grouping TLV, as described in [RFC4447] sec 5.3.2.2 208 -iv. a Transport LSP TLV. 209 -v. a label TLV for the upstream-assigned label R-PE to L-PE 210 direction. 211 -vi. MAY contain a downstream-assigned label for the L-PE to R-PE 212 direction. 214 The LDP liberal label retention mode is used, and per [RFC5036] 215 requirement the label request message MUST also be supported. 217 The Upstream-assigned label is allocated according to the rules in 218 [RFC5331]. 220 When a Leaf-PE receives a PW Label Mapping Message, it MUST verify 221 the associated P2MP transport LSP is in place. 223 If the associated transport P2MP LSP is not in place, and the 224 transport LSP TLV type is LDP P2MP LSP, a Leaf-PE SHOULD attempt to 225 join the P2MP transport associated with the P2MP PW. 227 If the associated transport P2MP LSP is not in place, and the 228 transport LSP TLV type is RSVP-TE P2MP LSP, a Leaf-PE SHOULD await 229 RSVP-TE P2MP LSP signaling from the Root-PE. 231 4.1. PW ingress to egress incompatibility issues 233 If a Root-PE signals a PW with a pw type, CW mode, or interface 234 parameters that a particular Leaf-PE cannot accept, then the L-PE 235 must simply not enable the PW, and notify the user. In this case a PW 236 status message of 0x00000001 - Pseudowire Not Forwarding MUST also be 237 sent to the R-PE. 239 Note that this procedure does not apply if the L-PE had not been 240 provisioned with this particular P2MP PW. In this case according to 241 the LDP liberal label retention rules, no action is taken. 243 4.2. P2MP PW FEC Element 245 [RFC4447] specifies two types of LDP FEC elements called "PWid FEC 246 Element" and "Generalized PWid FEC Element" used to signal P2P PWs. 247 We define a new type of FEC element called "P2MP PW FEC Element" 248 whose type is 0x82 (Pending IANA Allocation) and is encoded as 249 follows: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |FEC Type = 0x82|C| PW Type | PW Info Length| 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | AGI Type | Length | AGI Value | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ~ AGI Value (contd.) ~ 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | AII Type | Length | SAII Value | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 ~ SAII Value (contd.) ~ 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |0|0| Transport LSP TLV (0x0971)| Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Reserved |PMSI Tunnel Typ| Transport LSP ID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 ~ Transport LSP ID (contd.) ~ 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 | Optional Parameters | 275 ~ ~ 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 2: P2MP PW FEC Element 280 * PW Type: 282 15-bit representation of PW type, and the assigned values are 283 assigned by IANA. 285 * C bit: 287 A value of 1 or 0 indicates whether control word is present or 288 absent for the P2MP PW. 290 * PW Info Length: 292 Sum of the lengths of AGI, SAII and Optional Parameters field in 293 octets. If this value is 0, then it references all PWs using the 294 specified grouping ID. In this case, there are no other FEC 295 element fields (AGI, SAII, etc.) present, nor any interface 296 parameters TLVs. 298 * AGI: 300 Attachment Group Identifier can be used to uniquely identify VPN 301 or VPLS instance associated with the P2MP PW. This has the same 302 format as that of the Generalized PWid FEC element [RFC4447]. 304 * SAII: 306 Source Attachment Individual Identifier is used to identify the 307 root of the P2MP PW. The root is represented using AII type 2 308 format specified in [RFC5003]. Note that the SAII can be omitted 309 by simply setting the length and type to zero. 311 P2MP PW is identified by the Source Attachment Identifier (SAI). 312 If the AGI is non-null, the SAI is the combination of the SAII 313 and the AGI, if the AGI is null, the SAI is the SAII. 315 * Transport LSP TLV: 317 A P2MP PW MUST be associated with a transport LSP. The Transport 318 LSP TLV contains the information required to identify the 319 transport LSP. Note that the Transport LSP TLV MUST immediately 320 follow the FEC , but is not part of the FEC, and SHOULD NOT be 321 used in other messages where the FEC is used. 323 * Optional Parameters: 325 The Optional Parameter field can contain some TLVs that are not 326 part of the FEC, but are necessary for the operation of the PW. 327 This document defines two such parameters: Interface Parameters 328 TLV, and Group ID TLV. 330 The Interface Parameters TLV and Group ID TLV specified in [RFC4447] 331 can also be used in conjunction with P2MP PW FEC. For Group ID TLV 332 the sender and receiver of these TLVs should follow the same rules 333 and procedures specified in [RFC4447]. For Interface Parameters TLV 334 the procedure differs from the one specified in [RFC4447] due to 335 specifics of P2MP connectivity. When the interface parameters are 336 signaled by the Root-PE, the Leaf-PE must check if its configured 337 value(s) is less than or equal to the threshold value provided by the 338 Root-PE (e.g. MTU size (Ethernet), max number of concatenated ATM 339 cells, etc)). For other interface parameters like CEP/TDM Payload 340 bytes (TDM), the value MUST match exactly the the one signaled by the 341 Root-PE. 343 Note that since the LDP label mapping message is only sent by the R- 344 PE to all the L-PEs it is not possible to negotiate any interface 345 parameters. 347 4.3. Group ID usage 349 The Grouping TLV as defined in [RFC4447] contains a group ID capable 350 of indicating an arbitrary group membership of a P2MP-PW. This group 351 ID can be used in LDP "wild card" status, and withdraw label 352 messages, as described in [RFC4447]. 354 4.4. Generic Label TLV 356 For a given P2MP PW, a single upstream-assigned label is allocated by 357 the Root-PE, and is advertised to all Leaf-PEs using the Generic 358 Label TLV in the label mapping message containing the P2MP PW FEC 359 element. The Root-PE imposes the upstream-assigned label on the 360 outbound packets sent over the P2MP-PW, and using this label a Leaf- 361 PE identifies the inbound packets arriving over the P2MP PW. Even 362 though the P2MP PW is unidirectional, it may be possible for a Root- 363 PE to receive traffic from any Leaf-PE using a unidirectional P2P PW 364 in the reverse direction as outlined in [P2MP-PW-REQ]. For this 365 purpose, the Root-PE can also allocate a unique downstream-assigned 366 label for each Leaf-PE from which it is intended to receive P2P 367 traffic. In other words, Label Mapping Message for a P2MP PW from a 368 Root-PE to a Leaf-PE MUST carry a upstream-assigned label and MAY 369 carry an OPTIONAL downstream-assigned label. 371 As in the case of P2P PW signaling, P2MP PW labels are carried within 372 Generic Label TLV contained in LDP Label Mapping Message. A Generic 373 Label TLV is formatted and processed as per the rules and procedures 374 specified in [RFC4447]. But, as mentioned above, a Label Mapping 375 Message for a P2MP PW can have up to two Generic Label TLVs; one for 376 upstream-assigned label (always) and another for downstream-assigned 377 label (optional). In the case of two Generic Label TLVs, the first 378 TLV (from the beginning of the message) carries upstream-assigned 379 label and the next generic label TLV carries the downstream-assigned 380 label as shown below: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |0|0| Generic Label (0x0200) | Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Upstream-assigned P2MP Label (mandatory) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |0|0| Generic Label (0x0200) | Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Downstream-assigned P2P Label (optional) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 3: Generic Label TLVs in P2MP PW Label Mapping Message 396 Note that other type of TLVs may appear between the above generic 397 label TLVs, however any other generic label TLV MUST NOT appear 398 between the upstream-assigned P2MP Label TLV, and downstream-assigned 399 P2P Label TLV. 401 4.5. Transport LSP TLV 403 A P2MP PW MUST be associated with a transport LSP which can be 404 established using RSVP-TE or mLDP. Thus, a Label Mapping Message MUST 405 contain the identity of the transport LSP. For this purpose, this 406 specification introduces a new TLV called "Transport LSP TLV" which 407 has the following format: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |0|0| Transport LSP TLV (0x0971)| Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Reserved |PMSI Tunnel Typ| Tunnel Identifier | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 ~ Tunnel Identifier (contd.) ~ 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 4: Transport LSP TLV 422 Note: TLV number pending IANA allocation. 424 * Reserved Flags: 426 Reserved bits Must be set to 0 when transmitting the message, and 427 ignored on receiving the message. 429 * PMSI Tunnel Type: 431 The Transport LSP Type identifies the type of technology used to 432 establish a transport LSP. The PMSI tunnel type is defined in 433 [L3VPN-MCAST]. 435 Editor Comment: This is not finalized yet, as a new mLDP opaque 436 value needs to be used in place of this construct. This is 437 necessary to comply with the mLDP design principle of having a 438 mLDP LDP MP Opaque Value Element type per application. 440 * Tunnel Identifier: 442 The Tunnel containing the Transport LSP is identified by the 443 Tunnel Identifier which is defined in [L3VPN-MCAST]. 445 Transport LSP TLV MUST be present only in the Label Mapping Message. 446 An Root-PE sends Label Mapping Message as soon as the transport LSP 447 ID associated with the P2MP PW is known (e.g., via configuration) 448 regardless of the operational state of the transport LSP. Similarly, 449 a Root-PE does not withdraw the labels when the corresponding 450 transport LSP goes down. Furthermore, a Leaf-PE retains the P2MP PW 451 labels regardless of the operational status of the transport LSP. 453 Note that a given transport LSP can be associated with more than one 454 P2MP PW and all P2MP PWs will be sharing the same Root-PE and Leaf- 455 PE(s). 457 In the case of LDP P2MP LSP, when a Leaf-PE receives the Label 458 Mapping Message, it can initiate the process of joining the P2MP LSP 459 tree associated with the P2MP PW. 461 In the case of RSVP-TE P2MP LSP, only the Root-PE initiates the 462 signaling of P2MP LSP. 464 5. LDP Capability Negotiation 466 The capability of supporting P2MP PW must be advertised to all LDP 467 peers. This is achieved by using the methods in [RFC5561] and 468 advertising the P2MP PW LDP capability TLV. If an LDP peer supports 469 the dynamic capability advertisement, this can be done by sending a 470 new capability message with the S bit set for the P2MP PW capability 471 TLV. If the peer does not support dynamic capability advertisement, 472 then the P2MP PW TLV MUST be included in the LDP initialization 473 procedures in the capability parameter [RFC5561]. 475 In line with requirements listed in [RFC5561] the following TLV is 476 defined to indicate the P2MP PW capability: 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 |U|F| TLV Code Point=0x703 | Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 |S| Reserved | Reserved | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 5: P2MP PW LDP Capability TLV 488 Note: TLV number pending IANA allocation. 490 * U-bit: 492 SHOULD be 1 (ignore if not understood). 494 * F-bit: 496 SHOULD be 0 (don't forward if not understood). 498 * TLV Code Point: 500 The TLV type, which identifies a specific capability. The P2MP PW 501 capability code point is requested in the IANA allocation section 502 below. 504 * S-bit: 506 The State Bit indicates whether the sender is advertising or 507 withdrawing the P2MP PW capability. The State bit is used as 508 follows: 509 1 - The TLV is advertising the capability specified by the 510 TLV Code Point. 512 0 - The TLV is withdrawing the capability specified by the 513 TLV Code Point. 515 6. P2MP PW status 517 In order to support the proposed mechanism, a node MUST be capable of 518 handling PW status. As such, PW status negotiation procedure 519 described in [RFC4447] is not applicable to P2MP PW. 521 Once a Leaf-PE successfully process a Label Mapping Message for a 522 P2MP PW, it MUST send appropriate PW status according to the 523 procedure specified [RFC4447] to notify the PW status. If there is no 524 PW status notification required, then no PW status notification is 525 sent. (for example if the P2MP PW is established and operational with 526 a status 0f 0x00000000 no pw status message is necessary). 528 PW status message sent from any Leaf-PE to Root-PE contains P2MP PW 529 FEC to identify the PW. Finally, a Root-PE also sends PW status to 530 Leaf-PE(s) to reflect its view of a P2MP PW state. 532 Connectivity status of the underlying P2MP LSP that P2MP PW is 533 associated with, can be verified using LSP Ping and Traceroute 534 procedures described in [P2MP-LSP-PING]. 536 7. Security Considerations 538 The security measures described in [RFC4447] is adequate for the 539 proposed mechanism. 541 8. IANA Considerations 543 8.1. FEC Type Name Space 545 This document uses a new FEC element types, number 0x82 will be 546 requested as an allocation from the registry "FEC Type Name Space" 547 for the Label Distribution Protocol (LDP RFC5036): 549 Value Hex Name Reference 550 ------- ----- ----------------------------- --------- 551 130 0x82 P2MP PW FEC Element RFCxxxx 553 8.2. LDP TLV TYPE 555 This document uses a new LDP TLV types, IANA already maintains a 556 registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 557 following values are suggested for assignment: 559 TLV type Description 560 0x0971 Transport LSP TLV 561 0x0703 P2MP PW Capability TLV 563 9. References 565 9.1. Normative References 567 [RFC2119] Bradner. S, "Key words for use in RFCs to 568 Indicate Requirement Levels", RFC 2119, March, 1997. 570 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 571 et al., rfc4447 April 2006. 573 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 574 Specification", RFC 5036, October 2007. 576 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 577 Individual Identifier (AII) Types for Aggregation", RFC5003, 578 September 2007. 580 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 581 Assignment and Context-Specific Label Space", rfc5331, 582 August 2008. 584 [RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, 585 "MPLS Multicast Encapsulations", rfc5332, August 2008. 587 [mLDP] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label 588 Distribution Protocol Extensions for Point-to-Multipoint and 589 Multipoint-to-Multipoint Label Switched Paths", 590 draft-ietf-mpls-ldp-p2mp-06, Work In Progress, April 2009. 592 [RFC4875] 593 R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 594 "Extensions to Resource Reservation Protocol - Traffic 595 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 596 Switched Paths (LSPs).", rfc4875, May 2007. 598 [L3VPN-MCAST] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, 599 "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 600 VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, 601 Work in Progress, October 2009. 603 [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, 604 "LDP Capabilities", rfc5561, July 2009. 606 9.2. Informative References 608 [RFC3985] Stewart Bryant, et al., "PWE3 Architecture", 609 RFC3985 611 [BGP-AD] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, 612 Autodiscovery, and Signaling in L2VPNs", 613 draft-ietf-l2vpn-signaling-08.txt May 2006. 615 [P2MP-PW-REQ] F. Jounay, et. al, "Requirements for Point 616 to Multipoint Pseudowire", 617 draft-ietf-pwe3-p2mp-pw-requirements-02.txt, Work in Progress, 618 January 2010. 620 [P2MP-LSP-PING] A. Farrel, S. Yasukawa, "Detecting Data Plane 621 Failures in Point-to-Multipoint Multiprotocol Label Switching 622 (MPLS) - Extensions to LSP Ping", 623 draft-ietf-mpls-p2mp-lsp-ping-10.txt, Work In Progress, 624 March 2010. 626 10. Author's Addresses 628 Luca Martini 629 Cisco Systems, Inc. 630 9155 East Nichols Avenue, Suite 400 631 Englewood, CO, 80112 632 e-mail: lmartini@cisco.com 634 Sami Boutros 635 Cisco Systems, Inc. 636 170 West Tasman Drive 637 San Jose, CA 95134 638 e-mail: sboutros@cisco.com 639 Siva Sivabalan 640 2000 Innovation Drive 641 Kanata, ONTARIO K2K 3E8 642 CANADA 643 e-mail: msiva@cisco.com 645 Maciek Konstantynowicz 646 Juniper Networks 647 UNITED KINGDOM 648 e-mail: maciek@juniper.net 650 Gianni Del Vecchio 651 Swisscom (Schweiz) AG 652 Zentweg 9 653 CH-3006 Bern 654 Switzerland 655 e-mail: Gianni.DelVecchio@swisscom.com 657 Thomas D. Nadeau 658 BT 659 BT Centre 660 81 Newgate Street 661 London EC1A 7AJ 662 United Kingdom 663 e-mail: tom.nadeau@bt.com 665 Frederic Jounay 666 France Telecom 667 2, avenue Pierre-Marzin 668 22307 Lannion Cedex 669 FRANCE 670 Email: frederic.jounay@orange-ftgroup.com 672 Philippe Niger 673 France Telecom 674 2, avenue Pierre-Marzin 675 22307 Lannion Cedex 676 FRANCE 677 Email: philippe.niger@orange-ftgroup.com 678 Yuji Kamite 679 NTT Communications Corporation 680 Tokyo Opera City Tower 681 3-20-2 Nishi Shinjuku, Shinjuku-ku 682 Tokyo 163-1421 683 Japan 684 Email: y.kamite@ntt.com 686 Lizhong Jin 687 ZTE 688 889 Bibo Road, 689 Shanghai, 201203 690 P.R.China 691 Email: lizhong.jin@zte.com.cn 693 Martin Vigoureux 694 Alcatel-Lucent 695 Route de Villejust 696 Nozay, 91620 697 France 698 Email: martin.vigoureux@alcatel-lucent.com 700 Laurent Ciavaglia 701 Alcatel-Lucent 702 Route de Villejust 703 Nozay, 91620 704 France 705 Email: Laurent.Ciavaglia@alcatel-lucent.com 707 Simon Delord 708 Telstra 709 242 Exhibition Street 710 Melbourne, VIC, 3000, Australia 711 E-mail: simon.a.delord@team.telstra.com 713 Copyright Notice 715 Copyright (c) 2010 IETF Trust and the persons identified as the 716 document authors. All rights reserved. 718 This document is subject to BCP 78 and the IETF Trust's Legal 719 Provisions Relating to IETF Documents 720 (http://trustee.ietf.org/license-info) in effect on the date of 721 publication of this document. Please review these documents 722 carefully, as they describe your rights and restrictions with respect 723 to this document. Code Components extracted from this document must 724 include Simplified BSD License text as described in Section 4.e of 725 the Trust Legal Provisions and are provided without warranty as 726 described in the Simplified BSD License. 728 This document may contain material from IETF Documents or IETF 729 Contributions published or made publicly available before November 730 10, 2008. The person(s) controlling the copyright in some of this 731 material may not have granted the IETF Trust the right to allow 732 modifications of such material outside the IETF Standards Process. 733 Without obtaining an adequate license from the person(s) controlling 734 the copyright in such materials, this document may not be modified 735 outside the IETF Standards Process, and derivative works of it may 736 not be created outside the IETF Standards Process, except to format 737 it for publication as an RFC or to translate it into languages other 738 than English. 740 Acknowledgments 742 The authors wish to acknowledge the contributions of Ali Sajassi. 744 Expiration Date: January 2011