--- 1/draft-ietf-mpls-ldp-p2mp-01.txt 2007-11-06 23:50:30.000000000 +0100 +++ 2/draft-ietf-mpls-ldp-p2mp-02.txt 2007-11-06 23:50:30.000000000 +0100 @@ -1,22 +1,21 @@ Network Working Group I. Minei (Editor) Internet-Draft K. Kompella -Expires: December 27, 2006 Juniper Networks - I. Wijnands (Editor) +Intended status: Standards Track Juniper Networks +Expires: December 3, 2006 I. Wijnands (Editor) B. Thomas Cisco Systems, Inc. - June 25, 2006 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths - draft-ietf-mpls-ldp-p2mp-01 + draft-ietf-mpls-ldp-p2mp-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -27,21 +26,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 27, 2006. + This Internet-Draft will expire on December 3, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol @@ -62,41 +61,37 @@ 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 4 2.1. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 4 2.2. The LDP MP Opaque Value Element . . . . . . . . . . . . . 6 2.2.1. The Generic LSP Identifier . . . . . . . . . . . . . . 6 2.3. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 7 2.3.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 9 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 11 4.1. The MP2MP downstream and upstream FEC elements. . . . . . 11 - 4.2. Using the MP2MP FEC elements . . . . . . . . . . . . . . . 12 + 4.2. Using the MP2MP FEC elements . . . . . . . . . . . . . . . 11 4.2.1. MP2MP Label Map upstream and downstream . . . . . . . 13 4.2.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 15 - 5. mLDP wildcard FECs . . . . . . . . . . . . . . . . . . . . . . 16 - 5.1. Label Request Message . . . . . . . . . . . . . . . . . . 16 - 5.2. Label Withdraw Message . . . . . . . . . . . . . . . . . . 16 - 5.3. Label Release Message . . . . . . . . . . . . . . . . . . 17 - 6. Upstream label allocation on Ethernet networks . . . . . . . . 17 - 7. Root node redundancy for MP2MP LSPs . . . . . . . . . . . . . 17 - 7.1. Root node redundancy procedure . . . . . . . . . . . . . . 17 - 8. Make before break . . . . . . . . . . . . . . . . . . . . . . 18 - 8.1. Protocol event . . . . . . . . . . . . . . . . . . . . . . 19 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 - 12. Contributing authors . . . . . . . . . . . . . . . . . . . . . 20 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . . . . 24 + 5. Upstream label allocation on Ethernet networks . . . . . . . . 16 + 6. Root node redundancy for MP2MP LSPs . . . . . . . . . . . . . 16 + 6.1. Root node redundancy procedure . . . . . . . . . . . . . . 16 + 7. Make before break . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Protocol event . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 11. Contributing authors . . . . . . . . . . . . . . . . . . . . . 19 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . . . . 23 1. Introduction The LDP protocol is described in [1]. It defines mechanisms for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs in the network. This document describes extensions to LDP for setting up point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) LSPs. These are collectively referred to as multipoint LSPs (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) node to be delivered to a number of leaf (or egress) nodes. A MP2MP @@ -186,24 +181,21 @@ | Root Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Length | Opaque Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: The type of the P2MP FEC element is to be assigned by IANA, - such that the U-bit is set (=1) and the F-bit is clear (=0). This - ensures that an LSR which cannot process the P2MP FEC element, - silently ignores it. + Type: The type of the P2MP FEC element is to be assigned by IANA. Address Family: Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [3] that encodes the address family for the Root LSR Address. Address Length: Length of the Root LSR Address in octets. Root Node Address: A host address encoded according to the Address Family field. @@ -218,24 +210,20 @@ Address Lengths are defined at present. If the Address Length doesn't match the defined length for the Address Family, the receiver SHOULD abort processing the message containing the FEC Element, and send an "Unknown FEC" Notification message to its LDP peer signaling an error. If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST be the only FEC Element in the FEC TLV. - A P2MP FEC with the Root Node Address octets filled with zeros and - Opaque Length set to 0 is a wildcard P2MP FEC for all P2MPs FECs of - matching root node address family. - 2.2. The LDP MP Opaque Value Element The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC elements defined in subsequent sections. It carries information that is meaningful to leaf (and bud) LSRs, but need not be interpreted by non-leaf LSRs. The LDP MP Opaque Value Element is encoded as follows: 0 1 2 3 @@ -248,30 +236,29 @@ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The type of the LDP MP Opaque Value Element is to be assigned by IANA. Length: The length of the Value field, in octets. - Value: String of Length octets, to be interpreted as specified by the - Type field. + Value: String of Length octets, to be interpreted as specified by + the Type field. 2.2.1. The Generic LSP Identifier The generic LSP identifier is a type of Opaque Value Element encoded as follows: Type: 1 (to be assigned by IANA) - Length: 4 Value: A 32bit integer, unique in the context of the root, as identified by the root's address. This type of opaque value element is recommended when mapping of traffic to LSPs is non-algorithmic, and done by means outside LDP. 2.3. Using the P2MP FEC Element @@ -309,21 +296,21 @@ leaf node. 2.3.1. Label Map The following lists procedures for generating and processing P2MP Label Map messages for nodes that participate in a P2MP LSP. An LSR should apply those procedures that apply to it, based on its role in the P2MP LSP. For the approach described here we use downstream assigned labels. - On Ethernet networks this may be less optimal, see Section 6. + On Ethernet networks this may be less optimal, see Section 5. 2.3.1.1. Determining one's 'upstream LSR' A node Z that is part of P2MP LSP determines the LDP peer U which lies on the best path from Z to the root node X. If there are more than one such LDP peers, only one of them is picked. U is Z's "Upstream LSR" for . When there are several candidate upstream LSRs, the LSR MAY select one upstream LSR using the following procedure: @@ -341,42 +328,44 @@ single upstream LSR is selected. 2.3.1.2. Leaf Operation A leaf node Z of P2MP LSP determines its upstream LSR U for as per Section 2.3.1.1, allocates a label L, and sends a P2MP Label Map to U. 2.3.1.3. Transit Node operation - Suppose a transit node Z receives a P2MP Label Map over - interface I. Z checks whether it already has state for . If - not, Z allocates a label L', and installs state to swap L' with L - over interface I. Z also determines its upstream LSR U for as - per Section 2.3.1.1, and sends a P2MP Label Map to U. + Suppose a transit node Z receives a P2MP Label Map from LDP + peer T. Z checks whether it already has state for . If not, Z + allocates a label L', and installs state to swap L' with L over + interface I associated with peer T. Z also determines its upstream + LSR U for as per Section 2.3.1.1, and sends a P2MP Label Map + to U. If Z already has state for , then Z does not send a Label Map message for P2MP LSP . All that Z needs to do in this case is update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. 2.3.1.4. Root Node Operation - Suppose the root node Z receives a P2MP Label Map over - interface I. Z checks whether it already has forwarding state for . If not, Z creates forwarding state to push label L onto the - traffic that Z wants to forward over the P2MP LSP (how this traffic - is determined is outside the scope of this document). + Suppose the root node Z receives a P2MP Label Map from peer + T. Z checks whether it already has forwarding state for . If + not, Z creates forwarding state to push label L onto the traffic that + Z wants to forward over the P2MP LSP (how this traffic is determined + is outside the scope of this document). If Z already has forwarding state for , then Z adds "push label - L, send over interface I" to the nexthop. + L, send over interface I" to the nexthop, where I is the interface + associated with peer T. 2.3.2. Label Withdraw The following lists procedures for generating and processing P2MP Label Withdraw messages for nodes that participate in a P2MP LSP. An LSR should apply those procedures that apply to it, based on its role in the P2MP LSP. 2.3.2.1. Leaf Operation @@ -386,21 +375,23 @@ is the label it had previously advertised to U for . 2.3.2.2. Transit Node Operation If a transit node Z receives a Label Withdraw message from a node W, it deletes label L from its forwarding state, and sends a Label Release message with label L to W. If deleting L from Z's forwarding state for P2MP LSP results in no state remaining for , then Z propagates the Label - Withdraw to its upstream for . + Withdraw for , to its upstream T, by sending a Label Withdraw + where L1 is the label Z had previously advertised to T for + . 2.3.2.3. Root Node Operation The procedure when the root node of a P2MP LSP receives a Label Withdraw message are the same as for transit nodes, except that it would not propagate the Label Withdraw upstream (as it has no upstream). 2.3.2.4. Upstream LSR change @@ -482,28 +473,20 @@ 4.1. The MP2MP downstream and upstream FEC elements. The structure, encoding and error handling for the MP2MP downstream and upstream FEC elements are the same as for the P2MP FEC element described in Section 2.1. The difference is that two new FEC types are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element MUST be the only FEC Element in the FEC TLV. - A MP2MP Downstream FEC with the Root Node Address octets filled with - zeros and Opaque Length set to 0 is a wildcard MP2MP Downstream FEC - for all MP2MP Downstream FECs of matching root node address family. - Similarly, a MP2MP Upstream FEC with the Root Node Address octets - filled with zeros and Opaque Length set to 0 is a wildcard MP2MP - Upstream FEC for all MP2MP Upstream FECs of matching root node - address family. - 4.2. Using the MP2MP FEC elements This section defines the rules for the processing and propagation of the MP2MP FEC elements. The following notation is used in the processing rules: 1. MP2MP downstream LSP (or simply downstream ): an MP2MP LSP downstream path with root node address X and opaque value Y. @@ -575,82 +558,83 @@ Leaf node Z expects an MP2MP Label Map upstream from node U in response to the MP2MP Label Map downstream it sent to node U. Z checks whether it already has forwarding state for upstream . If not, Z creates forwarding state to push label Lu onto the traffic that Z wants to forward over the MP2MP LSP. How it determines what traffic to forward on this MP2MP LSP is outside the scope of this document. 4.2.1.4. MP2MP transit node operation - When node Z receives a MP2MP Label Map downstream over - interface I from node D it checks whether it has forwarding state for - downstream . If not, Z allocates a label L' and installs - downstream forwarding state to swap label L' with label L over - interface I. Z also determines its upstream LSR U for as per - Section 4.2.1.1, and sends a MP2MP Label Map downstream to - U. + When node Z receives a MP2MP Label Map downstream from peer + D associated with interface I, it checks whether it has forwarding + state for downstream . If not, Z allocates a label L' and + installs downstream forwarding state to swap label L' with label L + over interface I. Z also determines its upstream LSR U for as + per Section 4.2.1.1, and sends a MP2MP Label Map downstream to U. If Z already has forwarding state for downstream , all that Z needs to do is update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. Node Z checks whether it already has forwarding state upstream . If it does, then no further action needs to happen. If it does not, it allocates a label Lu and creates a new label swap for Lu from the label swap(s) from the forwarding state downstream , omitting the swap on interface I for node D. This allows upstream traffic to follow the MP2MP tree down to other node(s) except the node from which Z received the MP2MP Label Map downstream . Node Z determines the downstream MP2MP LSR as per Section 4.2.1.2, and sends a MP2MP Label Map upstream to node D. Transit node Z will also receive a MP2MP Label Map upstream in response to the MP2MP Label Map downstream sent to node U over - interface Iu. Node Z will add label swap Lu over interface Iu to the - forwarding state upstream . This allows packets to go up - the tree towards the root node. + Lu> in response to the MP2MP Label Map downstream sent to node U + associated with interface Iu. Node Z will add label swap Lu over + interface Iu to the forwarding state upstream . This allows + packets to go up the tree towards the root node. 4.2.1.5. MP2MP root node operation 4.2.1.5.1. Root node is also a leaf Suppose root/leaf node Z receives a MP2MP Label Map downstream over over interface I from node D. Z checks whether it already has - forwarding state downstream . If not, Z creates forwarding - state for downstream to push label L on traffic that Z wants to - forward down the MP2MP LSP. How it determines what traffic to - forward on this MP2MP LSP is outside the scope of this document. If - Z already has forwarding state for downstream , then Z will add - the label push for L over interface I to it. + L> from node D associated with interface I. Z checks whether it + already has forwarding state downstream . If not, Z creates + forwarding state for downstream to push label L on traffic that Z + wants to forward down the MP2MP LSP. How it determines what traffic + to forward on this MP2MP LSP is outside the scope of this document. + If Z already has forwarding state for downstream , then Z will + add the label push for L over interface I to it. Node Z checks if it has forwarding state for upstream . If not, Z allocates a label Lu and creates upstream forwarding state to push Lu with the label push(s) from the forwarding state downstream , except the push on interface I for node D. This allows upstream traffic to go down the MP2MP to other node(s), except the node from which the traffic was received. Node Z determines the downstream MP2MP LSR as per section Section 4.2.1.2, and sends a MP2MP Label Map upstream to node D. Since Z is the root of the tree Z will not send a MP2MP downstream map and will not receive a MP2MP upstream map. 4.2.1.5.2. Root node is not a leaf Suppose the root node Z receives a MP2MP Label Map dowbstream over over interface I from node D. Z checks whether it already has - forwarding state for downstream . If not, Z creates downstream - forwarding state and installs a outgoing label L over interface I. If - Z already has forwarding state for downstream , then Z will add - label L over interface I to the existing state. + L> from node D associated with interface I. Z checks whether it + already has forwarding state for downstream . If not, Z + creates downstream forwarding state and installs a outgoing label L + over interface I. If Z already has forwarding state for downstream + , then Z will add label L over interface I to the existing + state. Node Z checks if it has forwarding state for upstream . If not, Z allocates a label Lu and creates forwarding state to swap Lu with the label swap(s) from the forwarding state downstream , except the swap for node D. This allows upstream traffic to go down the MP2MP to other node(s), except the node is was received from. Root node Z determines the downstream MP2MP LSR D as per Section 4.2.1.2, and sends a MP2MP Label Map upstream to it. Since Z is the root of the tree Z will not send a MP2MP downstream map and will not receive a MP2MP upstream map. @@ -696,78 +680,40 @@ withdraw message is the same as for transit nodes, except that the root node would not propagate the Label Withdraw upstream (as it has no upstream). 4.2.2.4. MP2MP Upstream LSR change The procedure for changing the upstream LSR is the same as documented in Section 2.3.2.4, except it is applied to MP2MP FECs, using the procedures described in Section 4.2.1 through Section 4.2.2.3. -5. mLDP wildcard FECs - - P2MP, MP2MP Downstream and MP2MP Upstream FECs are examples of mLDP - Wildcard FECs. P2MP, and MP2MP Downstream Wildcard FECs may appear - only in Label Request, Label Withdraw and Label Release messages. - MP2MP Upstream Wildcard FECs may appear only in Label Withdraw and - Label Release messages. A label TLV object MUST not be present in - messages containing an mLDP wildcard FEC. - -5.1. Label Request Message - - Use of a Label Request Message is defined only for Wildcard versions - of the P2MP, and MP2MP Downstream FEC. An LSR sends a Label Request - Message containing an mLDP Wildcard FEC to requests the - readvertisement of all FECs of the specified address family. The - procedures defined above for various mLDP FEC types are to be - reapplied individually to any received Label Mapping advertisements. - -5.2. Label Withdraw Message - - An LSR sends a Label Withdraw Message containing an mLDP Wildcard FEC - when it wants to withdraw all the P2MP, MP2MP Upstream or MP2MP - Downstream FECs previously advertised. The same procedures defined - for the non Wildcard case apply except that instead of sending - individual label release messages only a single mLDP wildcard Label - Release message is sent to acknowledge completion of a mLDP wildcard - withdraw. - -5.3. Label Release Message - - An LSR sends an mLDP wildcard Label Release Message to acknowledge - the completion of processing for a mLDP wildcard withdraw. An LSR - may also send an unsolicited wildcard Label release to indicate to - that LDP neighbor that all previously send label mappings are to be - released. An LSR receiving an Label Release Message for a Wildcard - FEC MUST release all labels it assigned to this LSR for the given FEC - type and removes them from forwarding use. - -6. Upstream label allocation on Ethernet networks +5. Upstream label allocation on Ethernet networks On Ethernet networks the upstream LSR will send a copy of the packet to each receiver individually. If there is more then one receiver on the Ethernet we don't take full benefit of the multi-access capability of the network. We may optimize the bandwidth consumption on the Ethernet and replication overhead on the upstream LSR by using upstream label allocation [5]. Procedures on how to distribute upstream labels using LDP is documented in [6]. -7. Root node redundancy for MP2MP LSPs +6. Root node redundancy for MP2MP LSPs MP2MP leaf nodes must use the same root node to setup the MP2MP LSP. Otherwise there will be partitioned MP2MP LSP and traffic sourced by some leafs is not received by others. Having a single root node for a MP2MP LSP is a single point of failure, which is not preferred. We need a fast and efficient mechanism to recover from a root node failure. -7.1. Root node redundancy procedure +6.1. Root node redundancy procedure It is likely that the root node for a MP2MP LSP is defined statically. The root node address may be configured on each leaf statically or learned using a dynamic protocol. How MP2MP leafs learn about the root node is out of the scope of this document. A MP2MP LSP is uniquely identified by a opaque value and the root node address. Suppose that for the same opaque value we define two root node addresses and we build a tree to each root using the same opaque value. Effectively these will be treated as different MP2MP LSPs in the network. Since all leafs have setup a MP2MP LSP to each one of @@ -786,50 +732,50 @@ unicast routing table and select a root that is closest according in terms of unicast metric. As soon as the root address of our active root disappears from the unicast routing table (or becomes less attractive) due to root node or link failure we can select a new best root address and start forwarding to it directly. If multiple root nodes have the same unicast metric, the highest root node addresses MAY be selected, or we MAY do per session load balancing over the root nodes. All leafs participating in a MP2MP LSP MUST join to all the available - root nodes for a give opaque value. Since the sending leaf may pick + root nodes for a given opaque value. Since the sending leaf may pick any MP2MP LSP, it must be prepared to receive on it. The advantage of pre-building multiple MP2MP LSPs for a single opaque value is that we can converge from a root node failure as fast as the unicast routing protocol is able to notify us. There is no need for an additional protocol to advertise to the leaf nodes which root node is the active root. The root selection is a local leaf policy that does not need to be coordinated with other leafs. The disadvantage is that we are using more label resources depending on how many root nodes are defined. -8. Make before break +7. Make before break An upstream LSR is chosen based on the best path to reach the root of the MP LSP. When the best path to reach the root changes it needs to choose a new upstream LSR. Section 2.3.2.4 and Section 4.2.2.4 describes these procedures. When the best path to the root changes the LSP may be broken and packet forwarding is interrupted, in that case it needs to converge to a new upstream LSR ASAP. There are also scenarios where the best path changed, but the LSP is still forwarding packets. That happens when links come up or routing metrics are changed. In that case it would like to build the new LSP before it breaks the old LSP to minimize the traffic interruption. The approuch described below deals with both scenarios and does not require LDP to know which of the events above caused the upstream router to change. The approuch below is an optional extention to the MP LSP building procedures described in this draft. -8.1. Protocol event +7.1. Protocol event An approach is to use additional signaling in LDP. Suppose a downstream LSR-D is changing to a new upstream LSR-U for FEC-A, this LSR-U may already be forwarding packets for this FEC-A. Based on the existence of state for FEC-A, LSR-U will send a notification to the LSR-D to initiate the switchover. The assumption is that if our upstream LSR-U has state for the FEC-A and it has received a notification from its upstream router, then this LSR is forwarding packets for this FEC-A and it can send a notification back to initiate the switchover. You could say there is an explicit @@ -845,40 +791,40 @@ Suppose LSR-D sends a label mapping for FEC-A to LSR-U. LSR-U must only reply with a notification to LSR-D if it is in state #3 as described above. If LSR-U is in state 1 or 2, it should remember it has received a label mapping from LSR-D which is waiting for a notification. As soon as LSR-U received a notification from its upstream LSR it can move to state #3 and trigger notifications to its downstream LSR's that requested it. More details will be added in the next revision of the draft. -9. Security Considerations +8. Security Considerations The same security considerations apply as for the base LDP specification, as described in [1]. -10. IANA considerations +9. IANA considerations This document creates a new name space (the LDP MP Opaque Value Element type) that is to be managed by IANA. Also, this document requires allocation of three new LDP FEC element types: the P2MP type, the MP2MP-up and the MP2MP-down types. -11. Acknowledgments +10. Acknowledgments The authors would like to thank the following individuals for their review and contribution: Nischal Sheth, Yakov Rekhter, Rahul Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert and George Swallow. -12. Contributing authors +11. Contributing authors Below is a list of the contributing authors in alphabetical order: Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 US Email: Shane.Amante@Level3.com @@ -937,57 +883,58 @@ Norway Email: lei.wang@telenor.com IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium E-mail: ice@cisco.com -13. References +12. References -13.1. Normative References +12.1. Normative References [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [4] Roux, J., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", - draft-leroux-mpls-mp-ldp-reqs-01 (work in progress), July 2005. + draft-leroux-mpls-mp-ldp-reqs-03 (work in progress), + February 2006. [5] Aggarwal, R., "MPLS Upstream Label Assignment and Context Specific Label Space", draft-raggarwa-mpls-upstream-label-01 (work in progress), October 2005. [6] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for RSVP-TE and LDP", draft-raggarwa-mpls-rsvp-ldp-upstream-00 (work in progress), July 2005. -13.2. Informative References +12.2. Informative References [7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05 (work in progress), June 2004. - [8] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE - LSPs", draft-ietf-mpls-rsvp-te-p2mp-02 (work in progress), - July 2005. + [8] Aggarwal, R., "Extensions to RSVP-TE for Point-to-Multipoint TE + LSPs", draft-ietf-mpls-rsvp-te-p2mp-06 (work in progress), + August 2006. [9] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", - draft-ietf-l3vpn-2547bis-mcast-00 (work in progress), June 2005. + draft-ietf-l3vpn-2547bis-mcast-02 (work in progress), June 2006. Authors' Addresses Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: ina@juniper.net @@ -1009,21 +955,37 @@ Email: ice@cisco.com Bob Thomas Cisco Systems, Inc. 300 Beaver Brook Road Boxborough 01719 US Email: rhthomas@cisco.com -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. @@ -1033,30 +995,14 @@ such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - Acknowledgment - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).