Network Working Group R. Aggarwal (Juniper) Internet Draft D. Papadimitriou (Alcatel) Expiration Date: January 2005 S. Yasukawa (NTT) Editors Extensions to RSVP-TE for Point to Multipoint TE LSPs draft-raggarwa-mpls-rsvp-te-p2mp-00.txt Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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. Abstract This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 1]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. Table of Contents 1 Introduction............................................ 3 2 Terminology............................................. 4 3 Mechanisms.............................................. 4 3.1 P2MP Tunnels............................................ 4 3.2 P2P Sub-LSPs............................................ 5 3.2.1 Representation of a P2P sub-LSP......................... 5 3.2.2 P2P Sub-LSPs and Path Messages.......................... 5 3.3 Explicit Route Encoding................................. 6 4 Path Message Format..................................... 8 5 Path Message Processing................................. 9 5.1 Multiple Path Messages.................................. 10 5.2 Multiple P2P Sub-LSPs in One Path Message............... 10 6 RESV Message Format..................................... 12 7 RESV Message Processing................................. 13 7.1 RRO Processing.......................................... 13 7.2 Resv Message Throttling................................. 14 8 Grafting................................................ 14 9 Pruning................................................. 15 9.1 P2MP TE LSP Teardown.................................... 15 10 Refresh Reduction....................................... 15 11 Incremental State Update................................ 16 11.1 Using Refresh Reduction................................. 16 11.2 New Incremental State Procedures........................ 18 12 Error Processing........................................ 19 12.1 Branch Failure Handling................................. 20 13 Control of Branch Fate Sharing.......................... 21 14 Admin Status Change..................................... 21 15 Label Allocation on LANs with Multiple Downstream Nodes. 22 16 Make-Before-Break....................................... 22 16.1 P2MP Tree re-optimization............................... 22 16.2 Re-optimization of a subset of P2P sub-LSPs ............ 22 16.3 Control of Re-optimization.............................. 23 17 Fast Reroute............................................ 23 17.1 Facility Backpup........................................ 23 17.2 One to One Backup....................................... 24 18 Support for LSRs that are not P2MP Capable.............. 25 19 Reduction in Control Plane Processing with LSP Hierarchy 26 20 Re-merging Considerations............................... 27 21 New and Updated Message Objects......................... 27 draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 2]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 21.1 P2MP LSP SESSION Object................................. 27 21.1.1 P2MP IPv4 LSP SESSION Object............................ 28 21.1.2 P2MP IPv6 LSP SESSION Object............................ 28 21.2 Sender Template......................................... 29 21.3 P2P Sub-LSP Object...................................... 29 21.3.1 P2P IPv4 P2P Sub-LSP Object............................. 29 21.3.2 P2P IPv6 P2P Sub-LSP Object............................. 30 21.4 Filter Specification.................................... 30 21.5 SERO and SRRO........................................... 30 21.6 Sub-Group ID............................................ 30 22 IANA Considerations..................................... 31 23 Security Considerations................................. 32 24 Acknowledgements........................................ 32 25 Appendix................................................ 33 25.1 Example................................................. 33 26 References.............................................. 34 27 Authors................................................. 35 28 Intellectual Property................................... 38 29 Full Copyright Statement................................ 39 30 Acknowledgement......................................... 40 1. Introduction [RFC3209] defines a mechanism for setting up P2P TE tunnels in MPLS networks. [RFC3473] defines extensions to [RFC3209] for setting up P2P TE tunnels in GMPLS networks. However these specifications do not provide a mechanism for building P2MP TE tunnels. This document defines extensions to RSVP-TE [RFC3209] and [RFC3473] protocol to support P2MP TE LSPs satisfying the set of requirements described in [P2MP-REQ]. This document relies on the semantics of RSVP that RSVP-TE inherits for building P2MP TE LSPs. A P2MP TE LSP is comprised of multiple P2P TE sub-LSPs. These P2P sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple P2P sub-LSPs. Hence the P2P sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages. Path computation and P2MP application specific aspects are outside of the scope of this document. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 3]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 2. Terminology This document uses terminologies defined in [RFC3031], [RFC2205], [RFC3209], [RFC3473] and [P2MP-REQ]. In addition the following terms are used in this document. P2P sub-LSP: A P2MP TE LSP is constituted of one or more P2P sub- LSPs. A P2P sub-LSP refers to the label switched path from the ingress LSR to a particular egress LSR. The egress LSR is the destination of the P2P sub-LSP. 3. Mechanism A solution to the requirements specified in [P2MP-REQ] is to set up a full mesh of RSVP-TE P2P tunnels and replicate data intended, for a set of egress LSRs, at the ingress LSR. This has the obvious disadvantage of replication only at the edge of the network. This document describes a solution that optimizes data replication by allowing non-ingress nodes in the network to be replication/branch nodes. A branch node is a LSR that is capable of replicating the incoming data on one or more outgoing interfaces. The solution uses RSVP-TE in the core of the network for setting up a P2MP TE LSP. The P2MP TE LSP is set up by associating multiple P2P TE sub-LSPs and relying on data replication at branch nodes. This is described further in the following sub-sections by describing P2MP tunnels and how they relate to P2P sub-LSPs. 3.1. P2MP Tunnels The specific aspect related to P2MP TE LSP is the action required at a branch node, where data replication occurs. For instance, in the MPLS case, incoming labeled data is appropriately replicated to several outgoing interfaces with different labels. A P2MP TE tunnel comprises of one or more P2MP LSPs referred to as P2MP LSP tunnels. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the P2MP ID defined as a destination identifier, a tunnel ID and an extended tunnel ID. Note that the fields of this object are the same as the SESSION object (defined in [RFC 3209]) other than the fact that the destination address is a P2MP identifier and not an IP address of the egress node. This identifier encodes the P2MP ID and identifies the set of destination(s) of the P2MP LSP. A P2MP LSP tunnel is identified by the combination of the P2MP draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 4]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 SESSION object and the SENDER_TEMPLATE object. The SENDER_TEMPLATE object is the same as in [RFC3209]. The SENDER_TEMPLATE object contains the ingress LSR source address and the LSP ID. Multiple instances of the P2MP TE tunnel i.e. multiple P2MP LSP tunnels can be created, each with a different LSP ID. These P2MP LSP tunnels use different labels. If they are signaled using FF style reservation, they do not share QoS resources with each other. If they are signaled using SE style reservation, they can share QoS resources with each other. 3.2. P2P Sub-LSPs A P2MP LSP tunnel is constituted of one or more P2P sub-LSPs. The P2P sub-LSPs share the same P2MP session and have the same sender template. Label and QoS resources are shared between the P2P sub-LSPs that belong to the same P2MP LSP. The P2P sub-LSPs are identified uniquely as described below. 3.2.1. Representation of a P2P Sub-LSP Representation of a P2P sub-LSP consists of identifying the egress of the P2P sub-LSP and optionally specifying the explicit route of the P2P sub-LSP. As part of the identification of the egress of the P2P sub-LSP the destination address of the egress node is included. Identification of a P2P may also require assigning an identifier to each P2P sub-LSP as discussed in section 16. A new P2P_SUB_LSP object is used for identifying a P2P sub-LSP. The P2P_SUB_LSP object identifies a particular P2P sub-LSP belonging to the P2MP LSP. This object contains the IP destination address of the sub-LSP, i.e. the egress IP address, and it MAY contain an identifier of the sub-LSP. The need to encode a P2P sub-LSP identifier will depend on the outcome of the ongoing discussions on re-optimizing a subset of P2P sub-LSPs belonging to the same P2MP LSP (see Section 16). An EXPLICIT_ROUTE Object (ERO) or SUB_EXPLICIT_ROUTE Object (SERO) is used to specify the explicit route of a P2P sub-LSP. Each ERO or a SERO that is signaled corresponds to a particular P2P_SUB_LSP object. Details of explicit route encoding are specified in section 3.3 3.2.2. P2P Sub-LSPs and Path Messages The mechanism in this document allows a P2MP LSP to be signaled using one or more Path messages. Each Path message may signal one or more P2P sub-LSPs. Multiple Path messages are desirable as one Path message may not be large enough to fit all the P2P sub-LSPs; and they also allow separate manipulation of sub-trees of the P2MP LSP. The draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 5]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 reason for allowing a single Path message, to signal multiple P2P sub-LSPs, is to optimize the number of control messages needed to setup a P2MP LSP. 3.3. Explicit Route Encoding When a Path message signals a single P2P sub-LSP the EXPLICIT_ROUTE object encodes the path from the ingress LSR to the egress LSR. The Path message also encodes the P2P_SUB_LSP object for the P2P sub-LSP being signaled. The [<EXPLICIT_ROUTE>] <P2P_SUB_LSP> tuple represents the P2P sub-LSP. The absence of the ERO should be interpreted as requiring hop-by-hop routing for the sub-LSP. When a Path message signals multiple P2P sub-LSPs the path of the first P2P sub-LSP, from the ingress LSR to the egress LSR, is encoded in the ERO. The first P2P sub-LSP is the one that corresponds to the first P2P_SUB_LSP object in the Path message. The P2P sub-LSPs corresponding to the P2P_SUB_LSP objects that follow are termed as subsequent P2P sub-LSPs. The path of each subsequent P2P sub-LSP is encoded in a SUB_EXPLICIT_ROUTE object (SERO). The format of the SERO is the same as an ERO (as defined in [RFC3209]). Each subsequent P2P sub-LSP is represented by tuples of the form [<SUB_EXPLICIT_ROUTE>] <P2P_SUB_LSP>. There is a one to one correspondence between a P2P_SUB_LSP object and a SERO. The absence of a SERO should be interpreted as requiring hop-by-hop routing for that sub-LSP. Note that the destination address is carried in the P2P sub-LSP object. The encoding of the SERO and P2P sub-LSP object are described in detail in section 21. The motivation behind the use of the SERO object is to provide explicit route compression when a Path message signals simultaneously multiple P2P sub-LSPs. One approach to encode the explicit route of a subsequent P2P sub-LSP is to include the path from the ingress to the egress of the P2P sub-LSP. However this implies potential repetition of hops that can be learned from the ERO or explicit routes of other P2P sub-LSPs. Explicit route compression using SEROs attempts to minimize such repetition. A SERO for a particular P2P sub-LSP includes only the path from a certain branch LSR to the egress LSR if the path to that branch LSR can be derived from the ERO or other SEROs. Explicit route compression is illustrated using the following figure. A | | B draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 6]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 | | C----D----E | | | | | | F G H-------I | | | | | | J K L M | | | | | | | | N O P Q--R Figure 1. Explicit Route Compression Figure 1. shows a P2MP LSP with LSR A as the ingress LSR and six egress LSRs: (F, N, O, P, Q and R). When all the six P2P sub-LSPs are signaled in one Path message let us assume that the P2P sub-LSP to LSR F is the first P2P sub-LSP and the rest are subsequent P2P sub- LSPs. Following is one way for the ingress LSR A to encode the P2P sub-LSP explicit routes using compression: P2P sub-LSP-F: ERO = {B, E, D, C, F}, P2P_SUB_LSP Object-F P2P sub-LSP-N: SERO = {D, G, J, N}, P2P_SUB_LSP Object-N P2P sub-LSP-O: SERO = {E, H, K, O}, P2P_SUB_LSP Object-O P2P sub-LSP-P: SERO = {H, L, P}, P2P_SUB_LSP Object-P, P2P sub-LSP-Q: SERO = {H, I, M, Q}, P2P_SUB_LSP Object-Q, P2P sub-LSP-R: SERO = {Q, R}, P2P_SUB_LSP Object-R, After LSR E processes the incoming Path message from LSR B it sends a Path message to LSR D with the P2P sub-LSP explicit routes encoded as follows: P2P sub-LSP-F: ERO = {D, C, F}, P2P_SUB_LSP Object-F P2P sub-LSP-N: SERO = {D, G, J, N}, P2P_SUB_LSP Object-N LSR E also sends a Path message to LSR H and following is one way to encode the P2P sub-LSP explicit routes using compression: P2P sub-LSP-O: ERO = {H, K, O}, P2P_SUB_LSP Object-O P2P sub-LSP-P: SERO = {H, L, P}, P2P_SUB_LSP Object-P, P2P sub-LSP-Q: SERO = {H, I, M, Q}, P2P_SUB_LSP Object-Q, P2P sub-LSP-R: SERO = {Q, R}, P2P_SUB_LSP Object-R, After LSR H processes the incoming Path message from E it sends a Path message to LSR K, LSR L and LSR I. The encoding for the Path message to LSR K is as follows: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 7]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 P2P sub-LSP-O: ERO = {K, O}, P2P_SUB_LSP Object-O The encoding of the Path message sent by LSR H to LSR L is as follows: P2P sub-LSP-P: ERO = {L, P}, P2P_SUB_LSP Object-P, Following is one way for LSR H to encode the P2P sub-LSP explicit routes in the Path message sent to LSR I: P2P sub-LSP-Q: ERO = {I, M, Q}, P2P_SUB_LSP Object-Q, P2P sub-LSP-R: SERO = {Q, R}, P2P_SUB_LSP Object-R, The explicit route encodings in the Path messages sent by LSRs D and Q are left as an exercise to the reader. This compression mechanism reduces the Path message size. It also reduces extra processing that can result if explicit routes are encoded from ingress to egress for each P2P sub-LSP. No assumptions are placed on the ordering of the subsequent P2P sub-LSPs and hence on the ordering of the SEROs in the Path message. All LSRs need to process the ERO corresponding to the first P2P sub-LSP. A LSR needs to process a P2P sub-LSP descriptor for a subsequent P2P sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. The branch LSR that is the first hop of a SERO propagates the corresponding P2P sub-LSP downstream. Further processing details regarding the compression mechanism will be specified in the next revision of this document. 4. Path Message Format This section describes modifications made to the Path message format as specified in [RFC3209] and [RFC3473]. The Path message is enhanced to signal one or more P2P sub-LSPs. This is done by including the P2P sub-LSP descriptor list in the Path message as shown below. <Path Message> ::= <Common Header> [ <INTEGRITY> ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...] [ <MESSAGE_ID> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <EXPLICIT_ROUTE> ] <LABEL_REQUEST> [ <PROTECTION> ] [ <LABEL_SET> ... ] [ <SESSION_ATTRIBUTE> ] draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 8]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 [ <NOTIFY_REQUEST> ] [ <ADMIN_STATUS> ] [ <POLICY_DATA> ... ] [P2P sub-LSP descriptor list] <sender descriptor> Following is the format of the P2P sub-LSP descriptor list. <P2P sub-LSP descriptor list> ::= <P2P sub-LSP descriptor> | <P2P sub-LSP descriptor list> <P2P sub-LSP descriptor> <P2P sub-LSP descriptor> ::= <P2P_SUB_LSP> [ <SUB_EXPLICIT_ROUTE> ] Each LSR MUST use the common objects in the Path message and the P2P sub-LSP descriptors to process each P2P sub-LSP represented by the P2P sub-LSP object and the SUB/EXPLICIT_ROUTE object combination. The first P2P_SUB_LSP object's explicit route is specified by the ERO. Explicit routes of subsequent P2P sub-LSPs are specified by the corresponding SERO. A SERO corresponds to the following P2P_SUB_LSP object. The RRO in the sender descriptor contains the hops traversed by the Path message and applies to all the P2P sub-LSPs signaled in the Path message. Note that bi-directional P2MP TE LSPs are for further study. Path message processing is described in the next section. 5. Path Message Processing The ingress-LSR initiates the set up of a P2P sub-LSP to each egress- LSR that is the destination of the P2MP LSP. Each P2P sub-LSP is associated with the same P2MP LSP using a common P2MP SESSION object. Hence it can be combined with other P2P sub-LSPs to form a P2MP LSP. Another P2P sub-LSP belonging to the same instance of this P2P sub- LSP (i.e. the same P2MP LSP) can share resources with this LSP. The session corresponding to the P2MP TE tunnel is determined based on the P2MP SESSION object. Each P2P sub-LSP is identified using the P2P_SUB_LSP object. Explicit routing for the P2P sub-LSPs is done using the ERO and SEROs. As mentioned earlier it is possible to signal P2P sub-LSPs for a given P2MP LSP in one or more Path messages. And a given Path message can contain one or more P2P sub-LSPs. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 9]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 5.1. Multiple Path messages As described in section 4, <EXPLICIT_ROUTE> <P2P SUB-LSP> or <SUB_EXPLICIT_ROUTE> <P2P_SUB_LSP> combination is used to specify a P2P sub-LSP. Multiple Path messages can be used to signal a P2MP LSP. Each Path message can signal one or more P2P sub-LSPs. If a Path message contains only one P2P sub-LSP, each LSR along the P2P sub-LSP follows [RFC3209] procedures for processing the Path message besides the P2P SUB-LSP object processing described in this document. Note that even though different P2P sub-LSPs are signaled in separate ath messages, their state can be refreshed using the same Path message that contains multiple P2P sub-LSPs. Processing of Path messages containing more than one P2P sub-LSP is described in Section 5.2. (There is NO-CONSENSUS between the authors on rest of the text in this subsection and it needs further discussion.) Some ingress LSRs MAY choose to break the P2MP tree into separate manageable P2MP trees. These trees share the same root and may share the trunk and certain branches. The scope of this management decomposition of P2MP trees is bounded by a single tree (as described above) and multiple trees with a single leaf each. Each decomposed tree is signaled with a separate Path message sent by the ingress LSR. The resulting LSPs SHOULD share labels where they share hops to prevent multiple copies of the data being sent. Where (and only where) labels are shared, the LSPs MUST share resources. In order that resource sharing can be supported using conventional mechanisms, the decomposed trees MUST be signaled using the same session. In order to distinguish between Path messages, however, some difference is required within the SENDER_TEMPLATE object. In make- before- break and other functions, multiple LSPs within a session differ in the LSP ID, however, this results in the allocation of different labels. Thus a new 'Sub-Group ID' field is introduced as part of the SENDER_TEMPLATE object to distinguish the Path messages to support decomposed trees. 5.2. Multiple P2P Sub-LSPs in one Path message P2P sub-LSP descriptor list allows the signaling of one or more P2P sub-LSPs in one Path message. It is possible to signal multiple P2P sub-LSP object and ERO/SERO combinations in a single Path message. Note that these two objects are the ones that differentiate a P2P draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 10]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 sub-LSP. Each LSR can use the common objects in the Path message and the P2P sub-LSP descriptors to process each P2P sub-LSP. All LSRs need to process, when it is present, the ERO corresponding to the first P2P sub-LSP. If one or more SEROs are present an ERO must be present. The first P2P sub-LSP is propagated in a Path message by each LSR along the explicit route specified by the ERO. A LSR needs to process a P2P sub-LSP descriptor for a subsequent P2P sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. If this is not the case the P2P sub-LSP descriptor is included in the Path message sent to LSR that is the next hop to reach the first hop in the SERO. This next hop is determined by using the ERO or other SEROs that encode the path to the SERO's first hop. If this is the case and the LSR is also the egress the P2P sub-LSP descriptor is not propagated downstream. If this is the case and the LSR is not the egress the P2P sub-LSP descriptor is included in a Path message sent to the next-hop determined from the SERO. Hence a branch LSR only propagates the relevant P2P sub-LSP descriptors on each downstream link. A P2P sub- LSP descriptor that is propagated on a downstream link only contains those P2P sub-LSPs that are routed using that link. This processing may result in a subsequent P2P sub-LSP in an incoming Path message to become the first P2P sub-LSP in an outgoing Path message. Note that if one or more SEROs contain loose hops, expansion of such loose hops may result in overflowing the Path message size. Section 12 describes how signaling of the set of P2P sub-LSPs can be split in more than one Path message. The Record Route Object (RRO) contains the hops traversed by the Path message and applies to all the P2P sub-LSPs signaled in the path message. A transit LSR appends its address in an incoming RRO and propagates it downstream. A branch LSR forms a new RRO for each of the outgoing Path messages. Each such updated RRO is formed by appending the branch LSR's address to the incoming RRO. If a LSR is unable to support a P2P sub-LSP setup, a PathErr message MUST be sent for the impacted P2P sub-LSP, and normal processing of the rest of the P2MP LSP SHOULD continue. The default behavior is that the remainder of the LSP is not impacted (that is, all other branches are allowed to set up) and the failed branches are reported in PathErr messages in which the Path_State_Reomved flag MUST NOT be set. However, the ingress LSR may set a LSP Integrity flag (see section 21.6.2) to request that if there is a setup failure on any branch the entire LSP should fail to set up. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 11]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 6. Resv Message Format The Resv message follows the [RFC3209] and [RFC3473] format: <Resv Message> ::= <Common Header> [ <INTEGRITY> ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ <MESSAGE_ID> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] [ <SCOPE> ] [ <NOTIFY_REQUEST> ] [ <ADMIN_STATUS> ] [ <POLICY_DATA> ... ] <STYLE> <flow descriptor list> <flow descriptor list> ::= <FF flow descriptor list> | <SE flow descriptor> <FF flow descriptor list> ::= <FF flow descriptor> | <FF flow descriptor list> <FF flow descriptor> <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> <SE filter spec list> ::= <SE filter spec> | <SE filter spec list> <SE filter spec> The FF flow descriptor and SE filter spec are modified as follows to identify the P2P sub-LSPs that they correspond to: <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] [P2P sub-LSP descriptor] <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] [ <P2P sub-LSP descriptor> ] The FILTER_SPEC follows [RFC3209]. The P2P sub-LSP descriptor has the same format as in section 4.1 with the difference that a SUB_RECORD_ROUTE object is used in place of a SUB_EXPLICIT_ROUTE object. The SUB_RECORD_ROUTE objects follow the same compression mechanism as the SUB_EXPLICIT_ROUTE objects. Note that that a Resv message can signal multiple P2P sub-LSPs that may belong to the same FILTER_SPEC object or different FILTER_SPEC objects. The same label is allocated if the FILTER_SPEC object is the draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 12]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 same. However different upstream labels are allocated if the FILTER_SPEC object is different as that implies different P2MP LSPs. 7. Resv Message Processing The egress LSR follows normal RSVP procedures while originating a Resv message. The Resv message carries the label allocated by the egress LSR. A subsequent node allocates its own label and passes it in the Resv message upstream. The node may combine multiple flow descriptors, from different Resv messages received from downstream, in one Resv message sent upstream. A Resv message is not sent upstream until at least one Resv message has been received from a downstream neighbor except when the integrity bit is set in the LSP_ATTRIBUTE object. Each FF flow descriptor or SE filter spec sent upstream for the same P2MP LSP (whether on one or multiple Resv messages) is allocated the same label. This label is associated by that node with all the labels received from downstream Resv messages for that P2MP LSP. Note that a transit node may become a replication point in the future when a branch is attached to it. Hence this results in the setup of a P2MP LSP from the ingress-LSR to the egress LSRs. The ingress LSR may need to understand when all desired egresses have been reached. This is achieved using <P2P_SUB_LSP> objects. Each branch node can potentially send one Resv message upstream for each of the downstream receivers. This may result in overflowing the Resv message, particularly when considering that the number of messages increases the closer the branch node is to the ingress. To get around this problem the P2P sub-LSPs can be split across multiple Resv messages. Each P2P sub-LSP is self contained in the <P2P_SUB_LSP><RECORD_ROUTE> or <P2P_SUB_LSP><SUB_RECORD_ROUTE> tuple and that helps to achieve the splitting. This is discussed further in section 12. 7.1. RRO Processing A Resv message contains a record route per P2P sub-LSP that is being signaled by the Resv message if the sender node requests route recording by including a RRO in the Path message. The same rule is used during signaling of P2MP LSPs i.e. insertion of the RRO in the Path message used to signal one or more P2P sub-LSP triggers the inclusion of an RRO for each sub-LSP. The record route of the first P2P sub-LSP is encoded in the RRO. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 13]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 Additional RROs for the subsequent P2P sub-LSPs are referred to as SUB_RECORD_ROUTE objects (SRROs). Their format is specified in section 21. The ingress node then receives the RRO and possibly the SRRO corresponding to each subsequent P2P sub-LSP. Each P2P_SUB_LSP object is followed by the RRO/SRRO. The ingress node can then determine the record route corresponding to a particular P2P sub-LSP. The RRO and SRROs can be used to construct the end to end Path for each P2P sub-LSP. 7.2. Resv Message Throttling A branch node may have to send the Resv message being sent upstream whenever there is a change in a Resv message for a P2P sub-LSP received from downstream. This can result in excessive Resv messages sent upstream, particularly when the P2P sub-LSPs are established for the first time. In order to mitigate this situation, branch nodes can limit their transmission of Resv messages. Specifically, in the case where the only change being sent in a Resv message is in one or more SRRO objects, the branch node SHOULD transmit the Resv message only after a delay time has passed since the transmission of the previous Resv message for the same session. This delayed Resv message SHOULD include SRROs for all branches. Specific mechanisms for Resv message throttling are implementation dependent and are outside the scope of this document. 8. Grafting The operation of adding egress LSR(s) to an existing P2MP LSP is termed as grafting. This operation allows egress nodes to join a P2MP LSP at different points in time. The P2P sub-LSP(s) being added to the P2MP LSP are signaled in a Path message using mechanisms described in section 6. Note that the Path message contains only the P2P sub-LSP(s) being added and rest of the P2MP LSP does not have to be re-signaled. The egress LSRs can be added/removed by signaling only the impacted P2P sub-LSPs. Hence other P2P sub-LSPs do not have to be re-signaled. This is because the Path and PathTear messages have an incremental semantic. The processing on the LSRs that are on the path of the sub-tree is limited to the P2P sub-LSPs carried in the Path or PathTear message. Path message processing as described in section 6 results in adding these P2P sub-LSPs to the P2MP LSP. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 14]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 9. Pruning The operation of removing egress LSR(s) from an existing P2MP LSP is termed as pruning. This operation allows egress nodes to leave a P2MP LSP at different points in time. The P2P sub-LSP(s) being removed from the P2MP LSP are signaled in a PathTear message. The PathTear message includes the P2P sub-LSP descriptor list which is included before the sender descriptor. Note that the PathTear message contains only the P2P sub-LSP(s) being removed and rest of the P2MP LSP does not have to be re-signaled. This results in removal of the state corresponding to these P2P sub- LSPs. State for rest of the P2P sub-LSPs is not modified. 9.1. P2MP TE LSP Tear Down This operation is accomplished by listing all the P2P sub-LSPs in a PathTear message. 10. Refresh Reduction This section describes how refresh reduction [RFC2961] is used with the procedures described in this document. Section 1.1 of [RFC2961] categorizes RSVP messages into two types: trigger and refresh messages. Trigger messages are those RSVP messages that advertise new state or any other information not previously transmitted. Refresh messages represent previously advertised state and contain exactly the same objects and same information as a previously transmitted message. Refresh messages are identical to the corresponding previously transmitted message, with some possible exceptions detailed in [RFC 2961] [RFC2961] also introduces in Section 5, the summary refresh extension that enables the refreshing of RSVP state without the transmission of standard Path or Resv messages. Therefore, reducing the amount of information that must be transmitted and processed in order to maintain RSVP state synchronization. The Path and Resv trigger messages that establish the P2MP state can include a MESSAGE_ID object as per [RFC2961] procedures. The Srefresh message carries a list of Message_Identifier fields (carried in the MESSAGE ID LIST object) corresponding to the Path and Resv trigger messages that established the P2MP state. The MESSAGE_ID LIST object is used to refresh all Resv state, and Path state of P2MP sessions. It is made up of a list of Message_Identifier fields that were originally advertised in MESSAGE_ID objects. A node receiving a Srefresh message, matches each listed Message_Identifier field with draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 15]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 installed Path or Resv state for P2MP LSPs. Further processing follows [RFC2961] in terms state matching, and acknowledgment. 11. Incremental State Update (There is NO-CONSENSUS between the authors on this section. It needs further discussion.) RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and GMPLS [RFC3473] uses the same basic approach to state communication and synchronization, namely full state is sent in each state advertisement message. Per [RFC2205] Path and Resv messages are idempotent. Also, [RFC2961] categorizes RSVP messages into two types: trigger and refresh messages and improves RSVP message handling and scaling of state refreshes but does not modify the full state advertisement nature of Path and Resv messages. The full state advertisement nature of Path and Resv messages has many benefits, but also has some drawbacks. One notable drawback is when an incremental modification is being made to a previously advertised state. In this case, there is the message overhead of sending the full state and the cost of processing it. It is desirable to overcome this drawback and add/delete P2P sub-LSPs to a P2MP LSP by incrementally updating the existing state. It is possible to use the procedures described in this document to allow P2P sub-LSPs to be incrementally added or deleted from the P2MP LSP by allowing a Path or a PathTear message to incrementally change the existing P2MP LSP Path state. Discussions on this subject have shown there are two methods currently proposed to achieve this objective. Tthis section describes possible approaches to maintain the idempotent nature of RSVP Path messages; avoid keeping track of individual P2P sub-LSP state expiration and still have the ability to perform incremental state updates. The first approach reuses refresh reduction procedures as per [RFC2961] that are described in section 10. The second approach introduces new procedures to perform incremental state updates. 11.1. Using Refresh Reduction The use of refresh reduction preserves the idempotent nature of RSVP messages. A Message_ID is included in a RSVP message and the state advertised by this message is thereafter referenced by this particular Message_ID. Changes to this state are performed by advertising the full state (and including a higher Message_ID), hence this state update is idempotent per [RFC2205]. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 16]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 As described in [RFC2961], when a node is sending a refresh message, it SHOULD use the same Message_ID value that was used in the RSVP message that first advertised the state being refreshed. When a node is sending a trigger message, the Message_ID value MUST have a value that is greater than any other value previously used. Hence, if state management is performed on a per Message_ID (and not on a per P2P sub-LSP) basis, a set of P2P sub-LSPs can be advertised in a Path message using one Message_ID and another set of P2P sub-LSPs belonging to the same P2MP LSP can be advertised in a different Path message with a different Message_ID. The use of refresh reduction allows aggregate state management and incremental state update at the same time for P2MP LSPs while preserving the idempotent nature of RSVP Path and Resv messages. A LSR needs to keep track of state expiration per Message_ID. Since a Message_Identifier can correspond to multiple P2P sub-LSPs this allows aggregate state management as there is no need to keep track of state expiration of an individual P2P sub-LSP. Incremental P2P sub-LSP state update using [RFC2961] needs some clarification. There are different modes to add P2P sub-LSPs with refresh reduction enabled. Mode 1) A separate Path message with a new Message_ID is used to add the new P2P sub-LSPs. Each Path message refers to a Path state that is identified by the Message_ID [RFC2961]. Srefresh message is used to refresh the state associated with the existing Message_IDs and the new Message_ID. Mode 2) The new P2P sub-LSPs are added to an existing Path state. This is done by signaling the new P2P sub-LSPs along with the full state associated with an existing Message_ID, in a Path message with a new Message_ID. A LSR can use any of these modes to add a set of P2P sub-LSPs to a P2MP LSP. Consider, for example, that I P2P sub-LSPs have been setup with Message_ID(#1) and J sub-LSPs are being added: - Mode 1) Use a Message_ID(#2) to add the J P2P sub-LSPs using a separate Path message. Use Srefresh message to refresh the associated state by including Message_ID(#1) and Message_ID(#2) in the Message_ID List. - Mode 2) Use Message_ID(#2) for all I + J P2P sub-LSPs in a single Path message. This implies refreshing the full state associated with Message_ID(#2) and since the Path state for that Message_ID is draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 17]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 idempotent it updates the entire state. Now, consider for example that L P2P sub-LSPs are being added to the resulting I + J P2P sub-LSPs - Mode 1) Use a Message_ID(#3) to add the L P2P sub-LSPs using a separate Path message. Use Srefresh message to refresh the associated state by including Message_ID(#1), Message_ID(#2), Message_ID(#3) in the Message_ID List. - Mode 2) Use Message_ID(#3) for all I + J + L P2P sub-LSPs in a single Path message. This implies refreshing the full state associated with Message_ID(#3) and since the Path state for that Message_ID is idempotent it updates the entire state. This mode can be used until the size of the single Path/Resv message exceeds a threshold and then Mode_1 is to be used. - Combination of Mode_2 and Mode_1 i.e. Use a Message_ID(#3) to add the L P2P sub-LSPs using a separate Path message. Use Srefresh message to synchronize the entire associated state by including Message_ID(#2) and Message_ID(#3) in the Message_ID List. If K P2P sub-LSPs (with K < I + J) are being deleted from the set I + J P2P sub-LSPs, a PathTear (see Section 11) including the list of K P2P sub-LSPs is to be issued. The sender MUST also update the remaining (I + J) - K P2P sub-LSPs by issuing a Path message with a new Message_ID(#4) which updates the entire state associated with the remaining P2P sub-LSPs. 11.2. New Incremental State Update Procedures This section proposes to use new extensions to RSVP [RSVP-ISTATE] to support incremental state updates for P2MP LSPs. The use of updates does not replace full state advertisements, but rather augments them to optimize state change processing. The use of incremental state updates is on a hop-by-hop, not end-to-end, basis. A new category of RSVP messages called incremental messages is introduced [RSVP-IS]. Incremental messages are those that modify previously advertised state. Unlike trigger and refresh messages [RFC2961], incremental messages contain only a portion of the total set of objects sent in trigger and refresh messages. Incremental messages contain those objects needed to identify the state being modified, and the objects needed to represent the state modification. Incremental messages may also include objects that support hop-by-hop messaging, such as the INTEGRITY and MESSAGE_ID objects. Incremental Path and Resv messages are used to modify and add objects draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 18]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 to state previously advertised in Path and Resv messages. Incremental PathTear and ResvTear messages are used to remove objects from state previously advertised in Path and Resv messages. A representative ordering of messages when using incremental state update will be: (a) trigger message followed by (b) n or more refresh messages, where n >= 0, followed by (c) n or more incremental messages, where n >= 0, followed by (d) refresh messages - back to step (b) Errors in processing incremental messages are recovered via the next refresh message. For this reason, refresh message generation continues as normal even when using incremental state update. The summary refresh extensions defined in [RFC2961] are also supported and enable triggering an immediate refresh when a error processing an incremental message is encountered. It is suggested, but not required, that any implementation of the extensions defined in this section also implement the extensions defined in [RFC2961]. On receipt of an incremental message, the information contained in the incremental message is combined with the previously received state. This combination of state is based on the logical replacement of, addition to or removal of objects in the previously received refresh or trigger message. This logical combination yields the same state that will be sent in the next state refresh message. It also provides full information to the receiving node for processing the state change. A state instance value is used to verify that an incremental message is modifying the expected state. The state instance value is updated by incremental messages and established in trigger and refresh messages. The state instance value is scoped within advertised Path or Resv state, and is carried in the new STATE_INSTANCE object. Further details are provided in [RSVP-IS]. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 19]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 12. Error Processing PathErr and ResvErr messages are processed as per RSVP-TE procedures. Note that a LSR on receiving a PathErr/ResvErr message for a particular P2P sub-LSP changes the state only for that P2P sub-LSP. Hence other P2P sub-LSPs are not impacted. In case the ingress node requests the maintenance of the 'LSP integrity', any error reported within the P2MP TE LSP must be reported at (least at) any other branching nodes belonging to this LSP. Therefore, reception of an error message for a particular P2P sub-LSP MAY change the state of any other P2P sub- LSP of the same P2MP TE LSP. 12.1. Branch Failure Handling During setup and during normal operation, PathErr messages may be received at a branch node. In all cases, a received PathErr message is first processed per standard processing rules. That is: the PathErr message is sent hop-by-hop to the ingress/branch LSR for that Path message. Intermediate nodes until this ingress/branch LSR MAY inspect this message but take no action upon it. The behavior of a branch LSR that generates a PathErr message is under the control of the ingress LSR. The default behavior is that the PathErr does not have the Path_State_Removed flag set. However, if the ingress LSR has set the 'LSP integrity' flag on the Path message (see LSP_ATTRIBUTE object in section 21.6.2) and if the Path_State_Removed flag is supported, the LSR generating a PathErr to report the failure of a branch of the P2MP LSP SHOULD set the Path_State_Removed flag. A branch LSR that receives a PathErr message with the Path_State_Removed flag set MUST act according to the wishes of the ingress LSR. The default behavior is that the branch LSR clears the Path_State_Removed flag on the PathErr and sends it further upstream. It does not tear any other branches of the LSP. However, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all downstream branches and send the PathErr message upstream with the Path_State_Removed flag set. A branch LSR that receives a PathErr message with the Path_State_Removed flag clear MUST act according to the wishes of the ingress LSR. The default behavior is that the branch LSR forwards the PathErr upstream and takes no further action. However, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all downstream branches and send the PathErr upstream with the Path_State_Removed flag set (per [RFC3473]). In all cases, the PathErr message forwarded by a branch LSR MUST draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 20]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 contain the P2P sub-LSP identification and explicit routes of all branches that are errored (reported by received PathErr messages) and all branches that are explicitly torn by the branch LSR. 13. Control of Branch Fate Sharing An ingress LSR can control the behavior of an LSP if there is a failure during LSP setup or after an LSP has been established. The default behavior is that only the branches downstream of the failure are not established, but the ingress may request 'LSP integrity' such that any failure anywhere within the LSP tree causes the entire P2MP LSP to fail. The ingress LSP may request 'LSP integrity' by setting bit [TBD] of the Attributes Flags TLV. The bit is set if LSP integrity is required. It is RECOMMENDED to use the LSP_ATTRIBUTES Object for this flag and not the LSP_REQUIRED_ATTRIBUTES Object. A branch LSR that supports the Attributes Flags TLV and recognizes this bit MUST support LSP integrity or reject the LSP setup with a PathErr carrying the error "Routing Error"/"Unsupported LSP Integrity" 14. Admin Status Change A branch node that receives an ADMIN_STATUS object processes it normally and also relays the ADMIN_STATUS object in a Path on every branch. All Path messages may be concurrently sent to the downstream neighbors. Downstream nodes process the change in the status object per [RFC3473], including generation of Resv messages. When the last received upstream ADMIN_STATUS object had the R bit set, branch nodes wait for a Resv message with a matching ADMIN_STATUS object to be received (or a corresponding PathErr or ResvTear messsage) on all branches before relaying a corresponding Resv message upstream. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 21]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 15. Label Allocation on LANs with Multiple Downstream Nodes A sender on a LAN uses a different label for sending traffic to each node on the LAN that belongs to the P2MP LSP. Thus the sender performs replication. It may be considered desirable on a LAN to use the same label for sending traffic to multiple nodes belonging to the same P2MP LSP, to avoid replication. Procedures for doing this are for further study. Given the relatively small number of receivers on LANs typically deployed in MPLS networks, this is not currently seen as a practical problem. Furthermore avoiding replication at the sender on a LAN requires significant complexity in the control plane. Given the tradeoff we propose the use of replication by the sender on a LAN. 16. Make-before-break Let's consider the following cases where make-before-break is needed: 16.1. P2MP Tree re-optimization In this case all the P2P sub-LSPs are signaled with a different LSP ID by the ingress-LSR and follow the normal RSVP-TE make-before-break procedure. Thus a new P2MP TE LSP is established. Each P2P sub-LSP is signaled with a different LSP ID, corresponding to the new P2MP TE LSP. The ingress can, after moving traffic to the new instance, tear down the previous P2MP TE LSP. 16.2. Re-optimization of a subset of P2P sub-LSPs. One way to accomplish re-optimization of a subset of P2P sub-LSPs that belong to a P2MP LSP is to resignal the entire tree with a new LSP-ID as described in the previous subsection. (There is NO-CONSENSUS between the authors on rest of the text in this subsection and it needs further discussion.) It is possible to accomplish re-optimization of one or more P2P sub- LSPs without re-signaling rest of the P2MP LSP. To achieve this a sub-LSP ID is used to identify each P2P sub-LSP. This is encoded in the P2P sub-LSP object. Each re-optimized P2P sub-LSP is signaled with a different sub-LSP ID and hence a new P2P sub-LSP is established. Once the new setup is complete, the old P2P sub-LSP can be torn down. In some cases this may result in transient data duplication. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 22]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 16.3. Control of Reoptimization (The content of this section is for further discussion) An ingress LSR may wish to allow branch LSRs to independently reoptimize the parts of the P2MP tree that lie downstream. In networks where the topology is commonly available, and there is a shared understanding of the LSP routing paradigms, this may greatly reduce the burden on the ingress and the network in general. Permission to perform this function is indicated by bit [TBD] of the Attributes Flags TLV. The bit is set (1) if branch LSRs may reoptimize the downstream sub-trees. It is RECOMMENDED to use the LSP_ATTRIBUTES Object for this flag and not in the LSP_REQUIRED_ATTRIBUTES Object. A branch LSR that supports the Attributes Flags TLV and recognizes this bit but does not support reoptimization of sub-trees, MUST forward the bit unmodified. 17. Fast Reroute [RSVP-FR] extensions can be used to perform fast reroute for the mechanism described in this document. 17.1. Facility Backup Facility backup as described in [RSVP-FR] can be used to protect P2MP LSPs. If link protection is desired, a bypass tunnel is used to protect the link between the PLR and next-hop. Thus all P2P sub-LSPs that use the link can be protected in the event of link failure. Note that all such P2P sub-LSPs belonging to a particular instance of a P2MP tunnel will share the same outgoing label on the link between the PLR and the next-hop. This is the P2MP LSP label on the link. Label stacking is used to send data for each P2MP LSP in the bypass tunnel. The inner label is the P2MP LSP label allocated by the nhop. During failure Path messages for each P2P sub-LSP, that is effected, will be sent to the MP, by the PLR. It is recommended that the PLR use the sender template specific method to identify these Path messages. Hence the PLR will set the source address in the sender template to a local PLR address. The MP will use the LSP-ID to identify the corresponding P2P sub-LSPs. In order to further process a P2P sub-LSP it will determine the protected P2P sub-LSP using the LSP-id and the P2P sub-LSP object. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 23]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 If node protection is desired, the bypass tunnel must intersect the path of the protected P2P sub-LSPs somewhere downstream of the PLR. This constrains the set of P2P sub-LSPs being backed-up via that bypass tunnel to those that pass through a common downstream MP. The MP will allocate the same label to all such P2P sub-LSPs belonging to a particular instance of a P2MP tunnel. This will be the inner label used during label stacking. This may require the PLR to be branch capable as multiple bypass tunnels may be required to backup the set of P2P sub-LSPs passing through the protected node. Else all the P2P sub-LSPs being backed up must pass through the same MP. 17.2. One to One Backup One to one backup as described in [RSVP-FR] can be used to protect a particular P2P sub-LSP against link and next-hop failure. Protection may be used for one or more P2P sub-LSPs between the PLR and the next-hop. All the P2P sub-LSPs corresponding to the same instance of the P2MP tunnel, between the PLR and the next-hop share the same P2MP LSP label. All or some of these branch LSPs may be protected. The detour P2P sub-LSPs may or may not share labels, depending on the detour path. Thus the set of outgoing labels and next-hops for a P2MP LSP that was using a single next-hop and label between the PLR and next-hop before protection, may change once protection is triggerred. Its is recommended that the path specific method be used to identify a backup P2P sub-LSP. Hence the DETOUR object will be inserted in the backup Path message. A backup P2P sub-LSP MUST be treated as belonging to a different P2MP tunnel instance than the one specified by the LSP-id. Furthermore multiple backup P2P sub-LSPs MUST be treated as part of the same P2MP tunnel instance if they have the same LSP-id and the same DETOUR objects. Note that as specified in section 4 P2P sub-LSPs between different P2MP tunnel instances use different labels. If there is only P2P sub-LSP in the Path message, the DETOUR object applies to that sub-LSP. If there are multiple P2P sub-LSPs in the Path message the DETOUR applies to all the P2P sub-LSPs. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 24]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 18. Support for LSRs that are not P2MP Capable It may be that some LSRs in a network are capable of processing the P2MP extensions described in this document, but do not support P2MP branching in the data plane. If such an LSR is requested to become a branch LSR by a received Path message, it MUST respond with a PathErr message carrying the Error Value "Routing Error" and Error Code "Unable to Branch". Its conceivable that some LSRs, in a network deploying P2MP MPLS TE, may not support the extensions described in this document. If a Path message for the establishment of a P2MP LSP reaches such an LSR it will reject it with a PathErr because it will not recognize the C- Type of the P2MP SESSION object. LSRs that do not support the P2MP extensions in this document may be included as transit LSRs by the use of LSP-stitching and LSP- hierarchy [LSP-HIER]. Note that LSRs that are required to play any other role in the network (ingress, branch or egress) MUST support the extensions defined in this document. The use of LSP-stitching and LSP-hierarchy [LSP-HIER] allows to build P2MP LSPs in such an environment. A P2P LSP segment is signaled from the previous P2MP capable hop of a legacy LSR to the next P2MP capable hop. Of course this assumes that intermediate legacy LSRs are transit LSRs and cannot act as P2MP branch points. Transit LSRs along this LSP segment do not process control plane messages associated with a P2MP LSP. Furthermore these LSRs also do not need to have P2MP data plane capability as they only need to process data belonging to the P2P LSP segment. Hence these LSRs do not need to support P2MP MPLS. This P2P LSP segment is stitched to the incoming P2MP LSP. After the P2P LSP segment is established the P2MP Path message is sent to the next P2MP capable LSR as a directed Path message. The next P2MP capable LSR stitches the P2P LSP segment to the outgoing P2MP LSP. The P2P sub-LSPs may be nested inside the outer P2P LSP for packet networks. Hence label stacking can be used to enable use of the same LSP segment for multiple P2MP LSPs. Stitching and nesting considerations and procedures are described further in [INT-REG]. It may be an overhead for an operator to configure the P2P LSP segments in advance, when it is desired to support legacy LSRs. It may be desirable to do this dynamically. The ingress can use IGP extensions to determine non P2MP capable LSRs. It can use this information to compute P2P sub-LSP paths such that they avoid these legacy LSRs. The explicit route object of a P2P sub-LSP path may contain loose hops if there are legacy LSRs along the path. The draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 25]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 corresponding explicit route contains a list of objects upto the P2MP capable LSR that is adjacent to a legacy LSR followed by a loose object with the address of the next P2MP capable LSR. The P2MP capable LSR expands the loose hop using its TED. When doing this it determines that the loose hop expansion requires a P2P LSP to tunnel through the legacy LSR. If such a P2P LSP exists, it uses that P2P LSP. Else it establishes the P2P LSP. The P2MP Path message is sent to the next P2MP capable LSR using non-adjacent signaling. The P2MP capable LSR that initiates the non-adjacent signaling message to the next P2MP capable LSR may have to employ a fast detection mechanism such as [BFD] to the next P2MP capable LSR. This may be needed for the directed Path message headend to use node protection FRR when the protected node is the directed Path message tail. Note that legacy LSRs along a P2P LSP segment cannot perform node protection of the tail of the P2P LSP segment. 19. Reduction in Control Plane Processing with LSP Hierarchy It is possible to take advantage of LSP hierarchy [LSP-HIER] while setting up P2MP LSPs, as described in the previous section, to reduce control plane processing along transit LSRs that are P2MP capable. This is applicable only in environments where LSP hierarchy can be used. Transit LSRs along a P2P LSP segment, being used by a P2MP LSP, do not process control plane messages associated with the P2MP LSP. Infact they are not aware of these messages as they are tunneled over the P2P LSP segment. This reduces the amount of control plane processing required on these transit LSRs. Note that the P2P LSP segments can be dynamically setup as described in the previous section or preconfigured. For example in Figure 2, PE1 can setup a P2P LSP to P1 and use that as a LSP segment. The Path messages for PE3 and PE4 can now be tunneled over the LSP segment. Thus P3 is not aware of the P2MP LSP and does not process the P2MP control messages. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 26]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 20. Re-merging Considerations When a LSR receives data for the same P2MP LSP from at least two different P_HOPs this is termed as re-merging. The data for the P2P sub-LSPs that re-merge may be sent out by the LSR on the same or different interfaces. One case where re-merging can occur is when the ingress LSR signals a loose ERO or SEROs for P2P sub-LSPs. The ERO/SERO expansion may be performed by different LSRs and this may result in re-merging. Another case where re-merging can occur is when hop-by-hop routing is used for setting up the P2MP LSP. The control plane implication of re-merging is that a LSR should be able to receive incremental state for a P2MP LSP from different P_HOPs. This is possible with the mechanisms specified in this document as the Path messages have an incremental semantic. If the re-merged P2P sub-LSPs are sent out on different interfaces there is no data plane issue. However if the re-merged P2P sub-LSPs are sent out on the same interface it can result in data duplication downstream. The solution to this issue is for further study. 21. New and Updated Message Objects This section presents the RSVP message related formats as modified by this document. 21.1. P2MP LSP SESSION Object A P2MP LSP SESSION object is used. This object uses the existing SESSION C-Num. New C-Types are defined to accommodate a logical P2MP destination identifier. This SESSION object has a similar structure as the existing point to point RSVP-TE SESSION object. However the destination address is set to the P2MP ID instead of the egress unicast address. All P2P sub-LSPs share the same SESSION object. This SESSION object identifies the P2MP tunnel. The combination of the SESSION object, the sender template and the P2P sub-LSP object, identifies each P2P sub-LSP. This follows the existing P2P RSVP-TE notion of using the session for identifying a P2P tunnel which in turn can contain multiple LSPs, each distinguished by a unique sender template. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 27]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 21.1.1. P2MP IPv4 LSP SESSION Object Class = SESSION, LSP_TUNNEL_P2MP_IPv4 C-Type = TBD 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P2MP ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. It encodes the P2MP ID and identifies the destination of the P2MP LSP. Tunnel ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. Extended Tunnel ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv4 address here as a globally unique identifier [RFC3209]. 21.1.2. P2MP IPv6 LSP SESSION Object Class = SESSION, LSP_TUNNEL_P2MP_IPv6 C-Type = TBD This is same as the P2MP IPv4 LSP SESSION Object with the difference that the extended tunnel ID may be set to a 16 byte identifier [RFC3209]. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 28]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 21.2. Sender Template Each P2P sub-LSP is signaled using the P2P sender template [RFC3209]. The sender template contains the ingress-LSR source address. LSP ID can be can be changed to allow a sender to share resources with itself. Thus multiple instances of the P2MP tunnel can be created, each with a different LSP ID. The instances can share resources with each other, but use different labels. The P2P sub-LSPs corresponding to a particular instance use the same LSP ID. 21.3. P2P Sub-LSP Object A new P2P Sub-LSP object identifies a particular P2P sub-LSP belonging to the P2MP LSP. 21.3.1. P2P IPv4 P2P Sub-LSP Object SUB_LSP Class = TBD, P2MP_LSP_SUB_LSP_IPv4 C-Type = TBD 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 P2P sub-LSP destination address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Sub-LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 sub-LSP destination address IPv4 address of the P2P sub-LSP destination. (There is NO-CONSENSUS amongst the authors on the sub-LSP ID described below and it needs more discussion) Sub-LSP ID A 16-bit identifier that identifies a particular instance of a P2P sub-LSP. It can be varied for P2P sub-LSP make-before- break. Different P2P sub-LSPs, with the same SESSION object and LSP ID, follow the label merge semantics described in section 4 to form a particular instance of the P2MP tunnel. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 29]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 21.3.2. P2MP IPv6 P2P Sub-LSP Object SUB_LSP Class = TBD, P2MP_LSP_SUB_LSP_IPv6 C-Type = TBD This is same as the P2MP IPv4 P2P sub-LSP object, with the difference that the destination address is a 16 byte IPv6 address. 21.4. Filter Specification The filter specification object follows the same format as P2P filter specification [RFC3209]. 21.5. SERO and SRRO The SERO and SRRO are defined as identical to the ERO and RRO. The CNums are TBD and TBD of the form 11bbbbbb. (There is NO-CONSENSUS between the authors on the next subsection and it needs further discussion.) 21.6. Sub-Group ID As described in section 4.5 it is necessary to distinguish different Path messages sent for separate decomposed P2MP trees by using a Sub- Group ID. The SENDER_TEMPLATE object is modified to carry this information by making use of a reserved two-byte field as shown below. No change is made to the CNum or C-Type for the objects. The IPv4 SENDER_TEMPLATE is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group ID | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 tunnel sender address See [RFC3209] Sub-Group ID An identifier of a Path message used to establish a single element of a decomposed P2MP tree. This may be seen as draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 30]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 identifying a group of one or more egress nodes targeted by this Path message. LSP ID See [RFC3209] The IPv6 SENDER_TEMPLATE is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 tunnel sender address | + + | (16 bytes) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group ID | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 tunnel sender address See [RFC3209] Sub-Group ID As above. LSP ID See [RFC3209] 22. IANA Considerations 22.1. New Message Objects IANA considerations for new message objects will be specified after the objects used are decided upon. 22.2. New Error Codes Two new Error Codes are defined for use with the Error Value "Routing Error". IANA is requested to assign values. The Error Code "Unable to Branch" indicates that a P2MP branch cannot be formed by the reporting LSR. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 31]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 The Error Code "Unsupported LSP Integrity" indicates that a P2MP branch does not support the requested LSP integrity function. 22.3. LSP Attributes Flags IANA has been asked to manage the space of flags in the Attibutes Flags TLV carried in the LSP_ATTRIBUTES Object [LSP-ATTRIB]. This document defines two new flags as follows: Suggested Bit Number: 3 Meaning: LSP Integrity Required Used in Attributes Flags on Path: Yes Used in Attributes Flags on Resv: No Used in Attributes Flags on RRO: No Referenced Section of this Doc: 21.6.2 Suggested Bit Number: 4 Meaning: Branch Reoptimization Allowed Used in Attributes Flags on Path: Yes Used in Attributes Flags on Resv: No Used in Attributes Flags on RRO: No Referenced Section of this Doc: 21.6.1 23. Security Considerations This document does not introduce any new security issues. The security issues identified in [RFC3209] and [RFC3473] are still relevant. 24. Acknowledgements This document is the product of many people. The contributors are listed in Section 26. Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal Sheth for their suggestions and comments. Thanks also to Dino Farninacci for his comments. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 32]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 25. Appendix 25.1. Example Following is one example of setting up a P2MP LSP using the procedures described in this document. Source 1 (S1) | PE1 | | |L5 | P3 | | | L3 |L1 |L2 R2----PE3--P1 P2---PE2--Receiver 1 (R1) | L4 PE5----PE4----R3 | | R4 Figure 2. The mechanism is explained using Figure 2. PE1 is the ingress-LSR. PE2, PE3 and PE4 are Egress-LSRs. a) PE1 learns that PE2, PE3 and PE4 are interested in joining a P2MP tree with a P2MP ID of P2MP ID1. We assume that PE1 learns of the egress-LSRs at different points. b) PE1 computes the P2P path to reach PE2. c) PE1 establishes the P2P sub-LSP to PE2 along <PE1, P2, PE2> d) PE1 computes the P2P path to reach PE3 when it discovers PE3. This path is computed to share the same links where possible with the sub- LSP to PE2 as they belong to the same P2MP session. e) PE1 establishes the P2P sub-LSP to PE3 along <PE1, P3, P1, PE3> f) PE1 computes the P2P path to reach PE4 when it discovers PE4. This path is computed to share the same links where possible with the sub- LSPs to PE2 and PE3 as they belong to the same P2MP session. g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1, draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 33]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 PE4> e) P1 receives a Resv message from PE4 with label L4. It had previously received a Resv message from PE3 with label L3. It had allocated a label L1 for the sub-LSP to PE3. It uses the same label and sends the Resv messages to P3. Note that it may send only one Resv message with multiple flow descriptors in the flow descriptor list. If this is the case and FF style is used, the FF flow descriptor will contain the P2P sub-LSP descriptor list with two entries: one for PE4 and the other for PE3. For SE style, the SE filter spec will contain this P2P sub-LSP descriptor list. P1 also creates a label mapping of (L1 -> {L3, L4}). P3 uses the existing label L5 and sends the Resv message to PE1, with label L5. It reuses the label mapping of {L5 -> L1}. 26. References 26.1. Normative References [LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt. [LSP-ATTR] A. Farrel, et. al. , "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes-03.txt, March 2004, work in progress. [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, December 2001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003 [RFC3473] L. Berger et.al., "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473, January 2003. [RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 34]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RSVP-FR] P. Pan, D. Gan, G. Swallow, J. P. Vasseur, D. Cooper, A. Atlas, M. Jork, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt. [RSVP-IS] Lou Berger, "RSVP Incremental State Updates", work in progress, to be published. 26.2. Informative References [BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection", draft-katz-ward-bfd-01.txt. [BFD-MPLS] R. Aggarwal, K. Kompella, "BFD for MPLS LSPs", draft-raggarwa-mpls-bfd-00.txt [IPR-1] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [IPR-2] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [INT-REG] JP Vasseur, A. Ayyangar, "Inter-area and Inter-AS MPLS Traffic Engineering", draft-vasseur-ccamp-inter-area-as-te-00.txt. [P2MP-REQ] S. Yasukawa, et. al., "Requirements for Point-to-Multipoint capability extension to MPLS", draft-ietf-mpls-p2mp-requirement-01.txt. [RFC2209] R. Braden, L. Zhang, "Resource Reservation Protocol (RSVP) Version 1 Message Processing Rules", RFC 2209. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 35]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 27. Author Information 27.1. Editor Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4769 EMail: yasukawa.seisho@lab.ntt.co.jp Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be 27.2. Contributor Information John Drake Calient Networks Email: jdrake@calient.net Alan Kullberg Motorola Computer Group 120 Turnpike Road 1st Floor Southborough, MA 01772 EMail: alan.kullberg@motorola.com Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102 Phone: +1 703 847-1801 EMail: lberger@movaz.com Liming Wei draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 36]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 Redback Networks 350 Holger Way San Jose, CA 95134 Email: lwei@redback.com George Apostolopoulos Redback Networks 350 Holger Way San Jose, CA 95134 Email: georgeap@redback.com Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 Email: kireeti@juniper.net George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: swallow@cisco.com JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Dean Cheng Cisco Systems Inc. 170 W Tasman Dr. San Jose, CA 95134 Phone 408 527 0677 Email: dcheng@cisco.com Markus Jork Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 Phone: +1 978 964 2142 EMail: mjork@avici.com Hisashi Kojima NTT Corporation 9-11, Midori-Cho 3-Chome draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 37]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6070 EMail: kojima.hisashi@lab.ntt.co.jp Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134 Phone: +1 408 383 7223 Email: Andy.Malis@tellabs.com Koji Sugisono NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 2605 EMail: sugisono.koji@lab.ntt.co.jp Masanori Uga NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4804 EMail: uga.masanori@lab.ntt.co.jp Igor Bryskin Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102 Adrian Farrel Old Dog Consulting Phone: +44 0 1978 860944 EMail: adrian@olddog.co.uk Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France E-mail: jeanlouis.leroux@francetelecom.com draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 38]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 28. 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. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of 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. 29. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 39]
Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 30. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 40]