--- 1/draft-ietf-mpls-rsvp-te-p2mp-06.txt 2007-01-23 22:12:37.000000000 +0100 +++ 2/draft-ietf-mpls-rsvp-te-p2mp-07.txt 2007-01-23 22:12:37.000000000 +0100 @@ -1,22 +1,24 @@ Network Working Group R. Aggarwal (Editor) Internet Draft Juniper Networks -Expiration Date: January 2007 D. Papadimitriou (Editor) Alcatel S. Yasukawa (Editor) NTT + + January 2007 + Extensions to RSVP-TE for Point-to-Multipoint TE LSPs - draft-ietf-mpls-rsvp-te-p2mp-06.txt + draft-ietf-mpls-rsvp-te-p2mp-07.txt 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 @@ -87,21 +89,21 @@ 9 Refresh Reduction ..................................... 25 10 State Management ...................................... 25 10.1 Incremental State Update .............................. 25 10.2 Combining Multiple Path Messages ...................... 26 11 Error Processing ...................................... 27 11.1 PathErr Messages ...................................... 27 11.2 ResvErr Messages ...................................... 28 11.3 Branch Failure Handling ............................... 29 12 Admin Status Change ................................... 30 -13 Label Allocation on LANs with Multiple Downstream Nodes .30 +13 Label Allocation on LANs with Multiple Downstream Nodes ..30 14 P2MP LSP and Sub-LSP Re-optimization .................. 30 14.1 Make-before-break ..................................... 30 14.2 Sub-Group Based Re-optimization ....................... 31 15 Fast Reroute .......................................... 31 15.1 Facility Backup ....................................... 32 15.1.1 Link Protection ....................................... 32 15.1.2 Node Protection ....................................... 32 15.2 one-to-one Backup ..................................... 33 16 Support for LSRs that are not P2MP Capable ............ 34 17 Reduction in Control Plane Processing with LSP Hierarchy .36 @@ -126,21 +128,21 @@ 20 IANA Considerations ................................... 45 20.1 New Class Numbers ..................................... 45 20.2 New Class Types ....................................... 46 20.3 New Error Values ...................................... 46 20.4 LSP Attributes Flags .................................. 47 21 Security Considerations ............................... 47 22 Acknowledgements ...................................... 48 23 References ............................................ 48 23.1 Normative References .................................. 48 23.2 Informative References ................................ 49 -24 Appendix .............................................. 49 +24 Appendix .............................................. 50 24.1 Example ............................................... 50 25 Author Information .................................... 51 25.1 Editor Information .................................... 51 25.2 Contributor Information ............................... 52 26 Intellectual Property ................................. 54 27 Full Copyright Statement .............................. 54 28 Acknowledgement ....................................... 55 1. Conventions used in this document @@ -735,25 +737,25 @@ ::= [ ] FILTER_SPEC is defined in section 19.4. The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP descriptor in section 4.1 with the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP SECONDARY_EXPLICIT_ROUTE object. The P2MP_SECONDARY_RECORD_ROUTE objects follow the same compression mechanism as the P2MP - SECONDARY_EXPLICIT_ROUTE objects. Note that that a Resv message can - signal multiple S2L sub-LSPs that may belong to the same FILTER_SPEC - object or different FILTER_SPEC objects. The same label SHOULD be - allocated if the fields of the FILTER_SPEC - object are the same. + SECONDARY_EXPLICIT_ROUTE objects. Note that a Resv message can signal + multiple S2L sub-LSPs that may belong to the same FILTER_SPEC object + or different FILTER_SPEC objects. The same label SHOULD be allocated + if the fields of the FILTER_SPEC object are + the same. However different labels MUST be allocated if the of the FILTER_SPEC object is different as that implies that the FILTER_SPEC refers to a different P2MP LSP. 6.2. Resv Message Processing The egress LSR MUST follow normal RSVP procedures while originating a Resv message. The format of Resv messages is as defined in Section 6.1. As usual, the Resv message carries the label allocated by the @@ -812,23 +814,24 @@ whenever there is a change in a Resv message for an S2L sub-LSP received from one of the downstream neighbors. This can result in excessive Resv messages sent upstream, particularly when the S2L sub- LSPs are first established. 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. A - suggested value for the delay time is thirty seconds. Specific - mechanisms for Resv message throttling and delay timer settings are - implementation dependent and are outside the scope of this document. + suggested value for the delay time is thirty seconds, and delay times + SHOULD generally be longer than 1 second. Specific mechanisms for + Resv message throttling and delay timer settings are implementation + dependent and are outside the scope of this document. 6.3. Route Recording 6.3.1. RRO Processing A Resv message for a P2P LSP contains a recorded route if the ingress LSR requested route recording by including an RRO in the original Path message. The same rule is used during signaling of P2MP LSPs. That is, inclusion of an RRO in the Path message used to signal one or more S2L sub-LSPs triggers the inclusion of a recorded route for @@ -955,21 +958,21 @@ object on the received Notify message, and modify their values in the Notify message that is forwarded to match the sub-group field values in the original Path message received from upstream. The receiver of an (upstream) Notify message MUST identify the state referenced in this message based on the SESSION and SENDER_TEMPLATE. 2. Downstream Notification A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC - object(s) of a Resv message to the value, that was received in the + object(s) of a Resv message to the value that was received in the corresponding Path message. If the incoming Resv message carries a Notify Request object then: - If there is at least another incoming Resv message that carries a Notify Request object and the LSR merges these Resv messages into a single Resv message that is sent upstream, the LSR MUST set the Notify node address in the Notify Request object to its Router ID. - Else if the LSR sets the Sub-Group Originator ID in the outgoing Path message, that corresponds to the received Resv message, to its @@ -1013,21 +1016,21 @@ confirmation of receipt of the Resv message in P2MP TE LSPs. Processing not detailed in this section MUST comply to [RFC2205]. A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value, that was received in the corresponding Path message. If any of the incoming Resv messages corresponding to a single Path message carry a RESV_CONFIRM object then the LSR MUST include a RESV_CONFIRM object in the corresponding Resv message that it sends upstream. If the sub-group originator ID is its own address then it MUST set the receiver address in the - RESV_CONFIRM object to this addresse, else it MUST propagate the + RESV_CONFIRM object to this address, else it MUST propagate the object unchanged. A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If an incoming Resv message corresponding to a single Path message carries a RESV_CONFIRM object then the LSR MUST include a RESV_CONFIRM object in the corresponding Resv message that it sends upstream and: - If there is at least another incoming Resv message that carries a @@ -1272,21 +1275,21 @@ 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 ADMIN_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 + received (or a corresponding PathErr or ResvTear message) on all branches before relaying a corresponding Resv message upstream. 13. Label Allocation on LANs with Multiple Downstream Nodes A branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one copy of the data traffic per downstream LSR connected on that LAN for that P2MP LSP. Procedures for preventing MPLS labelled traffic replication in such a case is beyond the scope of this document. 14. P2MP LSP and Sub-LSP Re-optimization @@ -1440,25 +1443,25 @@ particular S2L sub-LSP against link and next-hop failure. Protection may be used for one or more S2L sub-LSPs between the PLR and the next-hop. All the S2L sub-LSPs corresponding to the same instance of the P2MP tunnel, between the PLR and the next-hop SHOULD share the same P2MP LSP label as per section 5.2.1. All such S2L sub-LSPs belonging to a P2MP LSP MUST be protected. The backup S2L sub-LSPs may traverse different next-hops at the PLR. 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. This MAY - require a PLR to be branch capable in the data plane. If the PLR is - not branch capable, the one-to-one backup mechanisms described here - are only applicable to those cases where all the backup S2L sub-LSPs - pass through the same next-hop downstream of the PLR. Procedures for + protection, may change once protection is triggered. This MAY require + a PLR to be branch capable in the data plane. If the PLR is not + branch capable, the one-to-one backup mechanisms described here are + only applicable to those cases where all the backup S2L sub-LSPs pass + through the same next-hop downstream of the PLR. Procedures for o one-to-one backup when a PLR is not branch capable and all the backup S2L sub-LSPs do not pass through the same downstream next-hop are for further study. It is recommended that the path specific method be used to identify a backup S2L sub-LSP. Hence the DETOUR object SHOULD be inserted in the backup Path message. A backup S2L sub-LSP MUST be treated as belonging to a different P2MP tunnel instance than the one specified by the LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be treated as part of the same P2MP tunnel instance if they have the @@ -1638,24 +1641,24 @@ allows the re-merge case to persist but data from all but one incoming interface is dropped at the re-merge node. In the second, the re-merge node initiates the removal of the re-merge branch(es) via signaling. Which approach is used is a matter of local policy. A node MUST support both approaches and MUST allow user configuration of which approach is to be used. When configured to allow a re-merge case to persist, the re-merge node MUST validate consistency between the objects included in the received Path message and the matching P2MP LSP Path state. Any - inconsistencies MUST result in an PathErr message sent to the - previous hop of the received Path message. The Error Code is set to - "Routing Problem" and the Error Value is set to "P2MP Re-Merge - Parameter Mistmatch". + inconsistencies MUST result in a PathErr message sent to the previous + hop of the received Path message. The Error Code is set to "Routing + Problem" and the Error Value is set to "P2MP Re-Merge Parameter + Mismatch". If there are no inconsistencies, the node logically merges, from the downstream perspective, the control state of incoming Path message with the matching P2MP LSP Path state. Specifically, procedures related to processing of messages received from upstream MUST NOT be modified from the upstream perspective; this includes refresh and state timeout related processing. In addition to the standard upstream related procedures, the node MUST ensure that each object received from upstream is appropriately represented within the set of Path messages sent downstream. For example, the received