idnits 2.17.1 draft-ietf-mpls-upstream-label-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2008) is 5766 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) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal 3 Internet Draft Juniper Networks 4 Category: Standards Track 5 Expiration Date: January 2009 Y. Rekhter 6 Juniper Networks 8 E. Rosen 9 Cisco Systems, Inc. 11 July 10, 2008 13 MPLS Upstream Label Assignment and Context-Specific Label Space 15 draft-ietf-mpls-upstream-label-07.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 RFC 3031 limits the MPLS architecture to downstream-assigned MPLS 43 labels. This document introduces the notion of upstream-assigned 44 MPLS labels. It describes the procedures for upstream MPLS label 45 assignment and introduces the concept of a "Context-Specific Label 46 Space". 48 Table of Contents 50 1 Specification of requirements ......................... 2 51 2 Introduction .......................................... 2 52 3 Context-Specific Label Space .......................... 3 53 4 Upstream Label Assignment ............................. 4 54 4.1 Upstream-Assigned and Downstream-Assigned Labels ...... 5 55 5 Assigning Upstream-Assigned Labels .................... 5 56 6 Distributing Upstream-Assigned Labels ................. 6 57 7 Upstream Neighbor Label Space ......................... 7 58 8 Context Label on LANs ................................. 9 59 9 Usage of Upstream-Assigned Labels ..................... 11 60 10 IANA Considerations ................................... 11 61 11 Security Considerations ............................... 11 62 12 Acknowledgements ...................................... 12 63 13 References ............................................ 12 64 13.1 Normative References .................................. 12 65 13.2 Informative References ................................ 12 66 14 Author's Address ...................................... 12 67 15 Intellectual Property Statement ....................... 13 68 16 Copyright Notice ...................................... 13 70 1. Specification of requirements 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Introduction 78 RFC 3031 [RFC3031] limits the MPLS architecture to downstream- 79 assigned MPLS labels. To quote from RFC 3031: 81 "In the MPLS architecture, the decision to bind a particular label L 82 to a particular Forwarding Equivalence Class (FEC) F is made by the 83 Label Switching Router (LSR) which is DOWNSTREAM with respect to that 84 binding. The downstream LSR then informs the upstream LSR of the 85 binding. Thus labels are "downstream-assigned", and label bindings 86 are distributed in the "downstream to upstream" direction." 88 This document introduces the notion of upstream-assigned MPLS labels 89 to the MPLS architecture. The procedures for upstream assignment of 90 MPLS labels are described. 92 RFC 3031 describes per-platform and per-interface label space. This 93 document generalizes the latter to a "Context-Specific Label Space" 94 and describes a "Neighbor Label Space" as an example of this. 95 Upstream-assigned labels are always looked up in a context-specific 96 label space. 98 3. Context-Specific Label Space 100 RFC 3031 describes per-platform and per-interface label spaces. This 101 document introduces the more general concept of a "Context-Specific 102 Label Space". A LSR may maintain one or more context-specific label 103 spaces. In general, labels MUST be looked up in the per-platform 104 label space unless something about the context determines that a 105 label be looked up in a particular context-specific label space. 107 One example of a context-specific label space is the per-interface 108 label space discussed in RFC 3031. When a MPLS packet is received 109 over a particular interface the top label of the packet may need to 110 be looked up in the receiving interface's per-interface label space. 111 In this case the receiving interface is the context of the packet. 112 Whether MPLS packets received over a particular interface need to 113 have their top labels looked up in a per-interface label space 114 depends on some characteristic or configuration of the interface. 116 Per-interface label space [RFC3031] is an example of a context- 117 specific label space used for downstream-assigned labels. Context- 118 specific label spaces can also be used for upstream-assigned labels, 119 as described below. 121 When MPLS labels are upstream-assigned the context of a MPLS label L 122 is provided by the LSR that assigns the label and binds the label to 123 a FEC F for a Label Switched Path (LSP) LSP1. The LSR that assigns 124 the label distributes the binding and context to a LSR Lr that then 125 receives MPLS packets on LSP1 with label L. When Lr receives a MPLS 126 packet on LSP1 it MUST be able to determine the context of this 127 packet. 129 An example of such a context is a Tunnel over which MPLS packets on 130 LSP1 may be received. In this case the top label of the MPLS packet, 131 after tunnel decapsulation, is looked up in a label space that is 132 specific to the root of the tunnel. This does imply that Lr be able 133 to determine the tunnel over which the packet was received. 134 Therefore, if the tunnel is a MPLS tunnel, penultimate-hop-popping 135 (PHP) MUST be disabled for the tunnel. 137 Another example of such a context is the neighbor from which MPLS 138 packets on LSP1 may be received. In this case the top label of the 139 MPLS packet, transmitted by the neighbor on LSP1, is looked up in a 140 "Neighbor Specific Label Space". 142 The above two examples are further described in section 7. 144 There may be other sorts of contexts as well. For instance, we define 145 the notion of a MPLS label being used to establish a context, i.e. 146 identify a label space. A "context label" is one which identifies a 147 label table in which the label immediately below the context label 148 should be looked up. A context label carried as an outermost label 149 over a particular multi-access subnet/tunnel MUST be unique within 150 the scope of that subnet/tunnel. 152 4. Upstream Label Assignment 154 When two MPLS LSRs are adjacent in a MPLS label switched path (LSP) 155 one of them can be termed an "upstream LSR" and the other a 156 "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have 157 agreed to bind Label L to a FEC, F, for packets sent from Ru to Rd. 158 Then with respect to this binding, Ru is the "upstream LSR", and Rd 159 is the "downstream LSR"." 161 If the binding between L and F was made by Rd and advertised to Ru, 162 then the label binding is known as "downstream-assigned". RFC 3031 163 only discusses downstream-assigned label bindings. 165 If the binding between L and F was made by Ru and advertised to Rd, 166 then the label binding is known as "upstream-assigned". 168 If the binding between L and F was made by a third party, say R3, and 169 then advertised to both Ru and Rd, we also refer to the label binding 170 as "upstream-assigned". 172 An important observation about upstream-assigned labels is the 173 following. When an upstream-assigned label L is at the top of the 174 label stack, it must be looked up by an LSR which is not the LSR that 175 assigned and distributed the label binding for L. Therefore an 176 upstream-assigned label MUST always be looked up in a context- 177 specific label space, as described in section 7. 179 We do not require any coordination between the upstream label 180 assignments and the downstream label assignments; a particular label 181 value may be upstream-assigned to one FEC and downstream-assigned to 182 a different FEC. 184 The ability to use upstream-assigned labels is an OPTIONAL feature. 185 Upstream-assigned labels MUST NOT be used unless it is known that the 186 downstream LSR supports them. 188 One use case of upstream-assigned labels is MPLS multicast and an 189 example of this is provided in section 9. 191 4.1. Upstream-Assigned and Downstream-Assigned Labels 193 It is possible that some LSRs on a LSP for FEC F, distribute 194 downstream-assigned label bindings for FEC F, while other LSRs 195 distribute upstream-assigned label bindings. It is possible for a LSR 196 to distribute a downstream-assigned label binding for FEC F to its 197 upstream adjacent LSR AND distribute an upstream-assigned label 198 binding for FEC F to its downstream adjacent LSR. When two LSRs Ru 199 and Rd are adjacent on an LSP for FEC F (with Ru being the upstream 200 neighbor and Rd the downstream neighbor), either Ru distributes an 201 upstream-assigned label binding for F to Rd, or else Rd distributes a 202 downstream-assigned label binding to Ru, but NOT both. Whether 203 upstream-assigned or downstream-assigned labels are to be used for a 204 particular FEC depends on the application using the LSP. 206 Any application which requires the use of upstream-assigned labels 207 MUST specify that explicitly, or else it is to be assumed that 208 downstream-assigned labels are used. An application on an LSR uses a 209 label distribution protocol to indicate to its peer LSRs whether a 210 particular label binding distributed by the LSR uses upstream- 211 assigned or downstream-assigned label. Details of such procedures are 212 outside the scope of this document. In some cases, the decision as to 213 which is used for a particular application may be made by a 214 configuration option. 216 5. Assigning Upstream-Assigned Labels 218 The only requirement on an upstream LSR assigning upstream-assigned 219 labels is that an upstream-assigned label must be unambiguous in the 220 context-specific label space in which the downstream LSR will look it 221 up. An upstream LSR which is the head end of multiple tunnels SHOULD 222 by default assign the upstream-assigned labels, for all the LSPs 223 carried over these tunnels, from a single label space, which is 224 common to all those tunnels. Further an upstream LSR which is the 225 head of multiple tunnels SHOULD use the same IP address as the head 226 identifier of these tunnels, provided that the head identifier of 227 these tunnels includes an IP address. The LSR could assign the same 228 label value to both a downstream-assigned and an upstream-assigned 229 label. The downstream LSR always looks up upstream-assigned MPLS 230 labels in a context-specific label space as described in section 7. 232 An entry for the upstream-assigned labels is not created in the 233 Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these 234 labels are not incoming labels. Instead an upstream label is an 235 outgoing label, with respect to the upstream LSR, for MPLS packets 236 transmitted on the MPLS LSP in which the upstream LSR is adjacent to 237 the downstream LSR. Hence an upstream label is part of a Next Hop 238 Label Forwarding Entry (NHLFE) at the upstream LSR. 240 When Ru advertises a binding of label L for FEC F to Rd, it creates a 241 NHLFE entry corresponding to L. This NHLFE entry results in imposing 242 the label L on the MPLS label stack of the packet forwarded using the 243 NHLFE entry. If Ru is a transit router on the LSP for FEC F, it 244 binds the ILM for the LSP to this NHLFE. If Ru is an ingress router 245 on the LSP for FEC F, it binds the FEC to the NHLFE entry. 247 6. Distributing Upstream-Assigned Labels 249 Upstream-assigned label bindings MUST NOT be used unless it is known 250 that the downstream LSR supports them. How this is known is outside 251 the scope of this document. 253 MPLS upstream label assignment requires a label distribution protocol 254 to distribute the binding from the upstream LSR to the downstream 255 LSR. Considerations that pertain to a label distribution protocol 256 that are described in [RFC3031] apply. 258 The distribution of the upstream-assigned labels is similar to either 259 the ordered LSP control or independent LSP control of the downstream- 260 assigned labels. In the former case a LSR distributes an upstream- 261 assigned label binding for a FEC F if it is either (a) the ingress 262 LSR for FEC F, or (b) if it has already received an upstream label 263 binding for that FEC from its adjacent upstream LSR for FEC F, or (c) 264 if it has received a request for a downstream label binding from its 265 upstream adjacent LSR. In the latter case each LSR, upon noting that 266 it recognizes a particular FEC, makes an independent decision to bind 267 an upstream-assigned label to that FEC and to distribute that binding 268 to its label distribution peers. 270 7. Upstream Neighbor Label Space 272 If the top label of a MPLS packet being processed by LSR Rd is 273 upstream-assigned, the label is looked up in a context-specific label 274 space, not in a per-platform label space. 276 Rd uses a context-specific label space that it maintains for Ru to 277 "reserve" MPLS labels assigned by Ru. Hence if Ru distributes an 278 upstream assigned label binding L for FEC F to Rd, then Rd reserves L 279 in the separate ILM for Ru's context-specific label space. This is 280 the ILM that Rd uses to lookup a MPLS label which is upstream- 281 assigned by Ru. This label may be the top label on the label stack of 282 a packet received from Ru or it may be exposed as the top label on 283 the label stack, as a result of Rd popping one or more labels off the 284 label stack, from such a packet. 286 This implies that Rd MUST be able to determine whether the top label 287 of a MPLS packet being processed is upstream-assigned and if yes, the 288 "context" of this packet. How this determination is made depends on 289 the mechanism that is used by Ru to transmit the MPLS packet with an 290 upstream-assigned top label L, to Rd. 292 If Ru transmits this packet by encapsulating it in an IP or MPLS 293 tunnel, then the fact that L is upstream-assigned is determined by Rd 294 by the tunnel on which the packet is received. Whether a given tunnel 295 can be used for transmitting MPLS packets with either downstream- 296 assigned or upstream assigned MPLS labels, or both, depends on the 297 tunnel type and is described in [MPLS-MCAST-ENCAPS]. When Rd receives 298 MPLS packets with a top label L on such a tunnel, it determines the 299 "context" of this packet based on the tunnel that the packet is 300 received on. There must be a mechanism for Ru to inform Rd that a 301 particular tunnel from Ru to Rd will be used by Ru for transmitting 302 MPLS packets with upstream-assigned MPLS labels. Such a mechanism 303 will be provided by the label distribution protocol between Ru and Rd 304 and will likely require extensions to existing label distribution 305 protocols. The description of such a mechanism is outside the scope 306 of this document. 308 Rd maintains an "Upstream Neighbor Label Space" for upstream assigned 309 labels, assigned by Ru. When Ru transmits MPLS packets the top label 310 of which is upstream assigned over IP or MPLS tunnels, then Rd MUST 311 be able to determine the root of these IP/MPLS tunnels. Rd MUST then 312 use a separate label space for each unique root. 314 The root is identified by the head-end IP address of the Tunnel. If 315 the same upstream router, Ru, uses different head-end IP addresses 316 for different tunnels then the downstream router, Rd, MUST maintain a 317 different Upstream Neighbor Label Space for each such head-end IP 318 address. 320 Consider the following conditions: 322 1) Ru is the "root" of two tunnels, call them A and B. 324 2) IP address X is an IP address of Ru. 326 3) The signaling protocol used to set up tunnel A identified A's 327 root node as IP address X. 329 4) The signaling protocol used to set up tunnel B identified B's 330 root node as IP address X. 332 5) Packets sent through tunnels A and B may be carrying upstream- 333 assigned labels. 335 6) Ru is the LSR that assigned the upstream-assigned labels 336 mentioned in condition 5. 338 If and only if these conditions hold, then Ru MUST use the same label 339 space when upstream-assigning labels for packets that travel through 340 tunnel A that it uses, when upstream-assigning labels for packets 341 that travel through tunnel B. 343 Suppose that Rd is a node that belongs to tunnels A and B, but is not 344 the root node of either tunnel. Then Rd may assume that the same 345 upstream-assigned label space is used on both tunnels IF AND ONLY IF 346 the signaling protocol used to set up tunnel A identified the root 347 node as IP address X and the signaling protocol used to set up tunnel 348 B identified the root node as the same IP address X. 350 In addition, the protocol that is used for distributing the upstream- 351 assigned label to be used over a particular tunnel MUST identify the 352 "assigner" using the same IP address that is used, by the protocol 353 that sets up the tunnel, to identify the root node of the tunnel. 354 Implementors must take note of this, even if the tunnel setup 355 protocol is different from the protocol that is used for distributing 356 the upstream-assigned label to be used over the tunnel. 358 The precise set of procedures for identifying the IP address of the 359 root of the tunnel depend, of course, on the protocol used to set up 360 the tunnel. For P2P tunnels, the intention is that the headend of the 361 tunnel is the "root". For P2MP or MP2MP tunnels, one can always 362 identify one node as being the "root" of the tunnel. 364 Some tunnels may be set up by configuration, rather than by 365 signaling. In these cases, the IP address of the root of the tunnel 366 must be configured. 368 Some tunnels may not even require configuration, e.g., a GRE tunnel 369 can be "created" just by encapsulating packets and transmitting them. 370 In such a case the IP address of the root is considered to be the IP 371 source address of the encapsulated packets. 373 If the tunnel on which Rd receives MPLS packets with a top label L is 374 a MPLS tunnel, then Rd determines a) That L is upstream-assigned and 375 b) The context for L, from the labels above L in the label stack. 376 Note that one or more of these labels may also be upstream-assigned 377 labels. 379 If the tunnel on which Rd receives MPLS packets with a top label L is 380 an IP/GRE tunnel then Rd determines a) That L is upstream-assigned 381 [MPLS-MCAST-ENCAPS] and b) The context for L, from the source address 382 in the IP header. 384 When Ru and Rd are adjacent to each other on a multi-access data link 385 media, if Ru would transmit the packet, with top label L, by 386 encapsulating it in a data link frame, then whether L is upstream- 387 assigned or downstream assigned can be determined by Rd as described 388 in [MPLS-MCAST-ENCAPS]. This is possible because if L is upstream- 389 assigned then [MPLS-MCAST-ENCAPS] uses a different ether type in the 390 data link frame. However this is not sufficient for Rd to determine 391 the context of this packet. In order for Rd to determine the context 392 of this packet, Ru encapsulates the packet, in a one hop MPLS tunnel. 393 This tunnel uses an MPLS context label that is assigned by Ru. 394 Section 8 describes how the context label is assigned. Rd maintains 395 a separate "Upstream Neighbor Label Space" for Ru. The "context" of 396 this packet, i.e. Ru's upstream neighbor label space, in which L was 397 reserved, is determined by Rd from the top context label and the 398 interface on which the packet is received. The ether type in the data 399 link frame is set to indicate that the top label is upstream- 400 assigned. The second label in the stack is L. 402 8. Context Label on LANs 404 For a labeled packet with an ether type of 'upstream label 405 assignment' the top label is used as the context. The context label 406 value is assigned by the upstream LSR and advertised to the 407 downstream LSRs. Mechanisms for advertising the context label will be 408 provided by the label distribution protocol between the upstream and 409 downstream LSRs. The description of such a mechanism is outside the 410 scope of this document. 412 The context label assigned by an LSR for use on a particular LAN 413 interface MUST be unique across all the context labels assigned by 414 other LSRs for use on the same LAN. When a labeled packet is received 415 from the LAN, the context label MUST be looked up in the context of 416 the LAN interface on which the packet is received. 418 This document provides two methods which an LSR can use to choose a 419 context label to advertise on a particular LAN. 421 The first method requires that each LSR be provisioned with a 20-bit 422 context label for each LAN interface on which a context label is 423 required. It is then left to the provisioning system to make sure 424 that an assigned context label is unique across the corresponding 425 LAN. 427 The second method allows the context labels to be auto-generated, but 428 is only applicable if each LSR on the LAN has an IPv4 address as its 429 primary IP address for the corresponding LAN interface. (If the LAN 430 contains LSRs that have only IPv6 addresses for the LAN interface, 431 then the first method is used.) 433 Suppose that each LAN interface is configured with a primary IPv4 434 address that is unique on that LAN. The host part of the IPv4 435 address, identified by the network mask, is unique. If the IPv4 436 network mask is greater then 12 bits, it is possible to map the 437 remaining 20 bits into a unique context label value. This enables the 438 LSRs on the LAN to automatically generate a unique context label. To 439 ensure that auto-generated context label values do not fall into the 440 reserved label space range [RFC3032], the value of the host part of 441 the IPv4 address is offset with 0x10, if this value is not greater 442 then 0xFFFEF. Values of the host part of the IPv4 address greater 443 then 0xFFFEF are not allowed to be used as context labels. 445 Consider LSRs Rm (downstream) connected to Ru1 (upstream) on a LAN 446 interface and to Ru2 (upstream) on a different LAN interface. Rm 447 could receive a context label value derived from the LAN interface 448 from Ru1 and from Ru2. It is possible that the context label values 449 used by Ru1 and Ru2 are the same. This would occur if the LAN 450 interfaces of both Ru1 and Ru2 are configured with a primary IPv4 451 address where the lowest 20 bits are equal. However, this does not 452 create any ambiguity, as it has already been stated that the context 453 label MUST be looked up in the context of the LAN interface on which 454 the packet is received. 456 9. Usage of Upstream-Assigned Labels 458 A typical use case of upstream-assigned labels is for MPLS multicast 459 and is described here for illustration. This use case arises when an 460 upstream LSR Ru is adjacent to several downstream LSRs in 461 a LSP LSP1 AND Ru is connected to via a multi-access 462 media or tunnel AND Ru wants to transmit a single copy of a MPLS 463 packet on the LSP to . In the case of a tunnel Ru can 464 distribute an upstream-assigned label L that is bound to the FEC for 465 LSP1, to and transmit a MPLS packet, the top label of 466 which is L, on the tunnel. In the case of a multi-access media Ru 467 can distribute an upstream-assigned label L that is bound to the FEC 468 for LSP1, to and transmit a MPLS packet, the top label of 469 which is the context label that identifies Ru, and the label 470 immediately below is L, on the multi-access media. Each of 471 will then interpret this MPLS packet in the context of Ru and forward 472 it appropriately. This implies that MUST all be able to 473 support an Upstream Neighbor Label Space for Ru and Ru MUST be able 474 to determine this. The mechanisms for determining this are specific 475 to the application that is using upstream-assigned labels and is 476 outside the scope of this document. 478 10. IANA Considerations 480 This document has no actions for IANA. 482 11. Security Considerations 484 The security considerations that apply to upstream-assigned labels 485 and context labels are no different in kind than those that apply to 486 downstream-assigned labels. 488 Note that procedures for distributing upstream-assigned labels and/or 489 context labels are not within the scope of this document. Therefore 490 the security considerations that may apply to such procedures are not 491 considered here. 493 Section 8 of this document describes a procedure which enables an LSR 494 to automatically generate a unique context label for a LAN. This 495 procedure assumes that the IP addresses of all the LSR interfaces on 496 the LAN will be unique in their low-order 20 bits. If two LSRs whose 497 IP addresses have the same low-order 20 bits are placed on the LAN, 498 other LSRs are likely to misroute packets transmitted to the LAN by 499 either of the two LSRs in question. 501 More detailed discussion of security issues that are relevant in the 502 context of MPLS and GMPLS, including security threats, related 503 defensive techniques, and the mechanisms for detection and reporting, 504 are discussed in "Security Framework for MPLS and GMPLS Networks 505 [MPLS-SEC]. 507 12. Acknowledgements 509 Thanks to IJsbrand Wijnands's contribution, specifically for the text 510 on which section 8 is based. 512 13. References 514 13.1. Normative References 516 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 517 RFC 3031. 519 [RFC2119] "Key words for use in RFCs to Indicate Requirement 520 Levels.", Bradner, March 1997 522 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, 523 draft-ietf-mpls-multicast-encaps-10.txt 525 13.2. Informative References 527 [RFC3032] E. Rosen, et. al., "MPLS Label Stack Encoding", January 528 2001. 530 [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS 531 Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-02.txt 533 14. Author's Address 535 Rahul Aggarwal 536 Juniper Networks 537 1194 North Mathilda Ave. 538 Sunnyvale, CA 94089 539 Email: rahul@juniper.net 541 Yakov Rekhter 542 Juniper Networks 543 1194 North Mathilda Ave. 544 Sunnyvale, CA 94089 545 Email: yakov@juniper.net 546 Eric C. Rosen 547 Cisco Systems, Inc. 548 1414 Massachusetts Avenue 549 Boxborough, MA 01719 550 Email: erosen@cisco.com 552 15. Intellectual Property Statement 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at ietf- 574 ipr@ietf.org. 576 16. Copyright Notice 578 Copyright (C) The IETF Trust (2008). 580 This document is subject to the rights, licenses and restrictions 581 contained in BCP 78, and except as set forth therein, the authors 582 retain all their rights. 584 This document and the information contained herein are provided on an 585 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 586 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 587 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 588 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 589 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 590 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.