draft-ietf-mpls-rsvp-te-p2mp-06.txt   draft-ietf-mpls-rsvp-te-p2mp-07.txt 
Network Working Group R. Aggarwal (Editor) Network Working Group R. Aggarwal (Editor)
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: January 2007
D. Papadimitriou (Editor) D. Papadimitriou (Editor)
Alcatel Alcatel
S. Yasukawa (Editor) S. Yasukawa (Editor)
NTT NTT
January 2007
Extensions to RSVP-TE for Point-to-Multipoint TE LSPs 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 4, line 5 skipping to change at page 4, line 5
9 Refresh Reduction ..................................... 25 9 Refresh Reduction ..................................... 25
10 State Management ...................................... 25 10 State Management ...................................... 25
10.1 Incremental State Update .............................. 25 10.1 Incremental State Update .............................. 25
10.2 Combining Multiple Path Messages ...................... 26 10.2 Combining Multiple Path Messages ...................... 26
11 Error Processing ...................................... 27 11 Error Processing ...................................... 27
11.1 PathErr Messages ...................................... 27 11.1 PathErr Messages ...................................... 27
11.2 ResvErr Messages ...................................... 28 11.2 ResvErr Messages ...................................... 28
11.3 Branch Failure Handling ............................... 29 11.3 Branch Failure Handling ............................... 29
12 Admin Status Change ................................... 30 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 P2MP LSP and Sub-LSP Re-optimization .................. 30
14.1 Make-before-break ..................................... 30 14.1 Make-before-break ..................................... 30
14.2 Sub-Group Based Re-optimization ....................... 31 14.2 Sub-Group Based Re-optimization ....................... 31
15 Fast Reroute .......................................... 31 15 Fast Reroute .......................................... 31
15.1 Facility Backup ....................................... 32 15.1 Facility Backup ....................................... 32
15.1.1 Link Protection ....................................... 32 15.1.1 Link Protection ....................................... 32
15.1.2 Node Protection ....................................... 32 15.1.2 Node Protection ....................................... 32
15.2 one-to-one Backup ..................................... 33 15.2 one-to-one Backup ..................................... 33
16 Support for LSRs that are not P2MP Capable ............ 34 16 Support for LSRs that are not P2MP Capable ............ 34
17 Reduction in Control Plane Processing with LSP Hierarchy .36 17 Reduction in Control Plane Processing with LSP Hierarchy .36
skipping to change at page 4, line 44 skipping to change at page 4, line 44
20 IANA Considerations ................................... 45 20 IANA Considerations ................................... 45
20.1 New Class Numbers ..................................... 45 20.1 New Class Numbers ..................................... 45
20.2 New Class Types ....................................... 46 20.2 New Class Types ....................................... 46
20.3 New Error Values ...................................... 46 20.3 New Error Values ...................................... 46
20.4 LSP Attributes Flags .................................. 47 20.4 LSP Attributes Flags .................................. 47
21 Security Considerations ............................... 47 21 Security Considerations ............................... 47
22 Acknowledgements ...................................... 48 22 Acknowledgements ...................................... 48
23 References ............................................ 48 23 References ............................................ 48
23.1 Normative References .................................. 48 23.1 Normative References .................................. 48
23.2 Informative References ................................ 49 23.2 Informative References ................................ 49
24 Appendix .............................................. 49 24 Appendix .............................................. 50
24.1 Example ............................................... 50 24.1 Example ............................................... 50
25 Author Information .................................... 51 25 Author Information .................................... 51
25.1 Editor Information .................................... 51 25.1 Editor Information .................................... 51
25.2 Contributor Information ............................... 52 25.2 Contributor Information ............................... 52
26 Intellectual Property ................................. 54 26 Intellectual Property ................................. 54
27 Full Copyright Statement .............................. 54 27 Full Copyright Statement .............................. 54
28 Acknowledgement ....................................... 55 28 Acknowledgement ....................................... 55
1. Conventions used in this document 1. Conventions used in this document
skipping to change at page 18, line 16 skipping to change at page 18, line 16
<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP> <S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
[ <P2MP_SECONDARY_RECORD_ROUTE> ] [ <P2MP_SECONDARY_RECORD_ROUTE> ]
FILTER_SPEC is defined in section 19.4. FILTER_SPEC is defined in section 19.4.
The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
descriptor in section 4.1 with the difference that a descriptor in section 4.1 with the difference that a
P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
SECONDARY_EXPLICIT_ROUTE object. The P2MP_SECONDARY_RECORD_ROUTE SECONDARY_EXPLICIT_ROUTE object. The P2MP_SECONDARY_RECORD_ROUTE
objects follow the same compression mechanism as the P2MP objects follow the same compression mechanism as the P2MP
SECONDARY_EXPLICIT_ROUTE objects. Note that that a Resv message can SECONDARY_EXPLICIT_ROUTE objects. Note that a Resv message can signal
signal multiple S2L sub-LSPs that may belong to the same FILTER_SPEC multiple S2L sub-LSPs that may belong to the same FILTER_SPEC object
object or different FILTER_SPEC objects. The same label SHOULD be or different FILTER_SPEC objects. The same label SHOULD be allocated
allocated if the <Sender Address, LSP-ID> fields of the FILTER_SPEC if the <Sender Address, LSP-ID> fields of the FILTER_SPEC object are
object are the same. the same.
However different labels MUST be allocated if the <Sender Address, However different labels MUST be allocated if the <Sender Address,
LSP-ID> of the FILTER_SPEC object is different as that implies that LSP-ID> of the FILTER_SPEC object is different as that implies that
the FILTER_SPEC refers to a different P2MP LSP. the FILTER_SPEC refers to a different P2MP LSP.
6.2. Resv Message Processing 6.2. Resv Message Processing
The egress LSR MUST follow normal RSVP procedures while originating a The egress LSR MUST follow normal RSVP procedures while originating a
Resv message. The format of Resv messages is as defined in Section 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 6.1. As usual, the Resv message carries the label allocated by the
skipping to change at page 19, line 46 skipping to change at page 19, line 46
whenever there is a change in a Resv message for an S2L sub-LSP 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 received from one of the downstream neighbors. This can result in
excessive Resv messages sent upstream, particularly when the S2L sub- excessive Resv messages sent upstream, particularly when the S2L sub-
LSPs are first established. In order to mitigate this situation, LSPs are first established. In order to mitigate this situation,
branch nodes can limit their transmission of Resv messages. branch nodes can limit their transmission of Resv messages.
Specifically, in the case where the only change being sent in a Resv 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 message is in one or more SRRO objects, the branch node SHOULD
transmit the Resv message only after a delay time has passed since transmit the Resv message only after a delay time has passed since
the transmission of the previous Resv message for the same session. the transmission of the previous Resv message for the same session.
This delayed Resv message SHOULD include SRROs for all branches. A This delayed Resv message SHOULD include SRROs for all branches. A
suggested value for the delay time is thirty seconds. Specific suggested value for the delay time is thirty seconds, and delay times
mechanisms for Resv message throttling and delay timer settings are SHOULD generally be longer than 1 second. Specific mechanisms for
implementation dependent and are outside the scope of this document. Resv message throttling and delay timer settings are implementation
dependent and are outside the scope of this document.
6.3. Route Recording 6.3. Route Recording
6.3.1. RRO Processing 6.3.1. RRO Processing
A Resv message for a P2P LSP contains a recorded route if the ingress 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 LSR requested route recording by including an RRO in the original
Path message. The same rule is used during signaling of P2MP LSPs. 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 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 or more S2L sub-LSPs triggers the inclusion of a recorded route for
skipping to change at page 23, line 12 skipping to change at page 23, line 12
object on the received Notify message, and modify their values object on the received Notify message, and modify their values
in the Notify message that is forwarded to match the sub-group in the Notify message that is forwarded to match the sub-group
field values in the original Path message received from upstream. field values in the original Path message received from upstream.
The receiver of an (upstream) Notify message MUST identify the state The receiver of an (upstream) Notify message MUST identify the state
referenced in this message based on the SESSION and SENDER_TEMPLATE. referenced in this message based on the SESSION and SENDER_TEMPLATE.
2. Downstream Notification 2. Downstream Notification
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC 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 corresponding Path message. If the incoming Resv message carries a
Notify Request object then: Notify Request object then:
- If there is at least another incoming Resv message that carries a - If there is at least another incoming Resv message that carries a
Notify Request object and the LSR merges these Resv messages into 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 single Resv message that is sent upstream, the LSR MUST set the
Notify node address in the Notify Request object to its Router ID. 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 - Else if the LSR sets the Sub-Group Originator ID in the outgoing
Path message, that corresponds to the received Resv message, to its Path message, that corresponds to the received Resv message, to its
skipping to change at page 24, line 22 skipping to change at page 24, line 22
confirmation of receipt of the Resv message in P2MP TE LSPs. confirmation of receipt of the Resv message in P2MP TE LSPs.
Processing not detailed in this section MUST comply to [RFC2205]. Processing not detailed in this section MUST comply to [RFC2205].
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC 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 any of the incoming Resv messages corresponding Path message. If any of the incoming Resv messages
corresponding to a single Path message carry a RESV_CONFIRM object corresponding to a single Path message carry a RESV_CONFIRM object
then the LSR MUST include a RESV_CONFIRM object in the corresponding then the LSR MUST include a RESV_CONFIRM object in the corresponding
Resv message that it sends upstream. If the sub-group originator ID 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 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. object unchanged.
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC 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 an incoming Resv message corresponding corresponding Path message. If an incoming Resv message corresponding
to a single Path message carries a RESV_CONFIRM object then the LSR to a single Path message carries a RESV_CONFIRM object then the LSR
MUST include a RESV_CONFIRM object in the corresponding Resv message MUST include a RESV_CONFIRM object in the corresponding Resv message
that it sends upstream and: that it sends upstream and:
- If there is at least another incoming Resv message that carries a - If there is at least another incoming Resv message that carries a
skipping to change at page 30, line 16 skipping to change at page 30, line 16
A branch node that receives an ADMIN_STATUS object processes it A branch node that receives an ADMIN_STATUS object processes it
normally and also relays the ADMIN_STATUS object in a Path on every normally and also relays the ADMIN_STATUS object in a Path on every
branch. All Path messages may be concurrently sent to the downstream branch. All Path messages may be concurrently sent to the downstream
neighbors. neighbors.
Downstream nodes process the change in the ADMIN_STATUS object per Downstream nodes process the change in the ADMIN_STATUS object per
[RFC3473], including generation of Resv messages. When the last [RFC3473], including generation of Resv messages. When the last
received upstream ADMIN_STATUS object had the R bit set, branch nodes 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 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. branches before relaying a corresponding Resv message upstream.
13. Label Allocation on LANs with Multiple Downstream Nodes 13. Label Allocation on LANs with Multiple Downstream Nodes
A branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one 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 copy of the data traffic per downstream LSR connected on that LAN for
that P2MP LSP. Procedures for preventing MPLS labelled traffic that P2MP LSP. Procedures for preventing MPLS labelled traffic
replication in such a case is beyond the scope of this document. replication in such a case is beyond the scope of this document.
14. P2MP LSP and Sub-LSP Re-optimization 14. P2MP LSP and Sub-LSP Re-optimization
skipping to change at page 34, line 4 skipping to change at page 34, line 4
particular S2L sub-LSP against link and next-hop failure. Protection 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 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 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 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 same P2MP LSP label as per section 5.2.1. All such S2L sub-LSPs
belonging to a P2MP LSP MUST be protected. belonging to a P2MP LSP MUST be protected.
The backup S2L sub-LSPs may traverse different next-hops at the PLR. 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 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 using a single next-hop and label between the PLR and next-hop before
protection, may change once protection is triggerred. This MAY protection, may change once protection is triggered. This MAY require
require a PLR to be branch capable in the data plane. If the PLR is a PLR to be branch capable in the data plane. If the PLR is not
not branch capable, the one-to-one backup mechanisms described here branch capable, the one-to-one backup mechanisms described here are
are only applicable to those cases where all the backup S2L sub-LSPs only applicable to those cases where all the backup S2L sub-LSPs pass
pass through the same next-hop downstream of the PLR. Procedures for 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 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 S2L sub-LSPs do not pass through the same downstream next-hop are for
further study. further study.
It is recommended that the path specific method be used to identify a 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 S2L sub-LSP. Hence the DETOUR object SHOULD be inserted in the
backup Path message. A backup S2L sub-LSP MUST be treated as backup Path message. A backup S2L sub-LSP MUST be treated as
belonging to a different P2MP tunnel instance than the one specified belonging to a different P2MP tunnel instance than the one specified
by the LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be 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 treated as part of the same P2MP tunnel instance if they have the
skipping to change at page 38, line 19 skipping to change at page 38, line 19
allows the re-merge case to persist but data from all but one 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, 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) 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 via signaling. Which approach is used is a matter of local policy. A
node MUST support both approaches and MUST allow user configuration node MUST support both approaches and MUST allow user configuration
of which approach is to be used. of which approach is to be used.
When configured to allow a re-merge case to persist, the re-merge When configured to allow a re-merge case to persist, the re-merge
node MUST validate consistency between the objects included in the node MUST validate consistency between the objects included in the
received Path message and the matching P2MP LSP Path state. Any received Path message and the matching P2MP LSP Path state. Any
inconsistencies MUST result in an PathErr message sent to the inconsistencies MUST result in a PathErr message sent to the previous
previous hop of the received Path message. The Error Code is set to hop of the received Path message. The Error Code is set to "Routing
"Routing Problem" and the Error Value is set to "P2MP Re-Merge Problem" and the Error Value is set to "P2MP Re-Merge Parameter
Parameter Mistmatch". Mismatch".
If there are no inconsistencies, the node logically merges, from the If there are no inconsistencies, the node logically merges, from the
downstream perspective, the control state of incoming Path message downstream perspective, the control state of incoming Path message
with the matching P2MP LSP Path state. Specifically, procedures with the matching P2MP LSP Path state. Specifically, procedures
related to processing of messages received from upstream MUST NOT be related to processing of messages received from upstream MUST NOT be
modified from the upstream perspective; this includes refresh and modified from the upstream perspective; this includes refresh and
state timeout related processing. In addition to the standard state timeout related processing. In addition to the standard
upstream related procedures, the node MUST ensure that each object upstream related procedures, the node MUST ensure that each object
received from upstream is appropriately represented within the set of received from upstream is appropriately represented within the set of
Path messages sent downstream. For example, the received <S2L sub-LSP Path messages sent downstream. For example, the received <S2L sub-LSP
skipping to change at page 46, line 27 skipping to change at page 46, line 27
C-Type C-Type
12 P2MP_LSP_IPv4 C-Type 12 P2MP_LSP_IPv4 C-Type
13 P2MP_LSP_IPv6 C-Type 13 P2MP_LSP_IPv6 C-Type
Class Name = FILTER_SPEC Class Name = FILTER_SPEC
C-Type C-Type
12 P2MP LSP_IPv4 C-Type 12 P2MP LSP_IPv4 C-Type
13 P2MP LSP_IPv6 C-Type 13 P2MP LSP_IPv6 C-Type
Class Name = SECONDARY_EXPLICIT_ROUTE Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RECOVERY])
C-Type C-Type
2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type 2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type
Class Name = SECONDARY_RECORD_ROUTE Class Name = SECONDARY_RECORD_ROUTE (Defined in [RECOVERY])
C-Type C-Type
2 P2MP_SECONDARY_RECORD_ROUTE C-Type 2 P2MP_SECONDARY_RECORD_ROUTE C-Type
20.3. New Error Values 20.3. New Error Values
Four new Error Values are defined for use with the Error Code Four new Error Values are defined for use with the Error Code
"Routing Problem". IANA is requested to assign values. "Routing Problem". IANA is requested to assign values.
The Error Value "Unable to Branch" indicates that a P2MP branch The Error Value "Unable to Branch" indicates that a P2MP branch
skipping to change at page 47, line 14 skipping to change at page 47, line 14
Value. Value.
The Error Value "P2MP Re-Merge Parameter Mismatch" is described in The Error Value "P2MP Re-Merge Parameter Mismatch" is described in
section 18. IANA is requested to assign value 26 to this Error Value. section 18. IANA is requested to assign value 26 to this Error Value.
The Error Value "ERO Resulted in Remerge" is described in section 18. The Error Value "ERO Resulted in Remerge" is described in section 18.
IANA is requested to assign value 27 to this Error Value. IANA is requested to assign value 27 to this Error Value.
20.4. LSP Attributes Flags 20.4. LSP Attributes Flags
IANA has been asked to manage the space of flags in the Attibutes IANA has been asked to manage the space of flags in the Attributes
Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES Object [RFC4420]. Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES Object [RFC4420].
This document defines a new flag as follows: This document defines a new flag as follows:
Suggested Bit Number: 3 Suggested Bit Number: 3
Meaning: LSP Integrity Required Meaning: LSP Integrity Required
Used in Attributes Flags on Path: Yes Used in Attributes Flags on Path: Yes
Used in Attributes Flags on Resv: No Used in Attributes Flags on Resv: No
Used in Attributes Flags on RRO: No Used in Attributes Flags on RRO: No
Referenced Section of this Doc: 5.2.4 Referenced Section of this Doc: 5.2.4
skipping to change at page 47, line 44 skipping to change at page 47, line 44
specified in this document, particularly in sections 16 and 17. specified in this document, particularly in sections 16 and 17.
An administration may wish to limit the domain over which P2MP TE An administration may wish to limit the domain over which P2MP TE
tunnels can be established. This can be accomplished by setting tunnels can be established. This can be accomplished by setting
filters on various ports to deny action on a RSVP path message with a filters on various ports to deny action on a RSVP path message with a
SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6. SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6.
The ingress LSR of a P2MP TE LSP, determines the leaves of the P2MP The ingress LSR of a P2MP TE LSP, determines the leaves of the P2MP
TE LSP based on the application of the P2MP TE LSP. The specification TE LSP based on the application of the P2MP TE LSP. The specification
of how such applications will use a P2MP TE LSP is outside the scope of how such applications will use a P2MP TE LSP is outside the scope
of this document. However these applications SHOULD provide of this document. Applications MUST provide a mechanism to notify the
mechanisms to ensure that unauthorized leaves are not added to the ingress LSR of the appropriate leaves for the P2MP LSP.
P2MP TE LSP. Specifications of applications within the IETF MUST specify this
mechanism in sufficient detail that an ingress LSR from one vendor
can be used with an application implementation provided by another
vendor. Manual configuration of security parameters when other
parameters are auto-discovered is generally not sufficient to meet
security and interoperability requirements of IETF specifications.
22. Acknowledgements 22. Acknowledgements
This document is the product of many people. The contributors are This document is the product of many people. The contributors are
listed in Section 27.2. listed in Section 27.2.
Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal
Sheth for their suggestions and comments. Thanks also to Dino Sheth for their suggestions and comments. Thanks also to Dino
Farninacci and Benjamin Niven for their comments. Farninacci and Benjamin Niven for their comments.
23. References 23. References
23.1. Normative References 23.1. Normative References
[RFC4206] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized [RFC4206] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
MPLS TE" [RFC4206] MPLS TE" [RFC4206]
[RFC4420] A. Farrel, et. al. , "Encoding of [RFC4420] A. Farrel, et al. , "Encoding of
Attributes for Multiprotocol Label Switching (MPLS) Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE", Label Switched Path (LSP) Establishment Using RSVP-TE",
RFC 4420, February 2006. RFC 4420, February 2006.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001, work in progress. RFC3209, December 2001, work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997, work in Requirement Levels", BCP 14, RFC 2119, March 1997, work in
skipping to change at page 48, line 43 skipping to change at page 48, line 47
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReSerVation Protocol (RSVP) S. Jamin, "Resource ReSerVation Protocol (RSVP)
-- Version 1, Functional Specification", RFC 2205, -- Version 1, Functional Specification", RFC 2205,
September 1997, work in progress. September 1997, work in progress.
[RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling [RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling
Functional Description", RFC 3471, January 2003, work in Functional Description", RFC 3471, January 2003, work in
progress. progress.
[RFC3473] L. Berger et.al., "Generalized MPLS Signaling - RSVP-TE [RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE
Extensions", RFC 3473, January 2003, work in progress. Extensions", RFC 3473, January 2003, work in progress.
[RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, [RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi,
S. Molendini, "RSVP Refresh Overhead Reduction S. Molendini, "RSVP Refresh Overhead Reduction
Extensons", RFC 2961, April 2001, work in progress. Extensions", RFC 2961, April 2001, work in progress.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001, Label Switching Architecture", RFC 3031, January 2001,
work in progress. work in progress.
[RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute [RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", work in progress. Extensions to RSVP-TE for LSP Tunnels", work in progress.
[RFC3477] K. Kompella, Y. Rekther, "Signalling Unnumbered Links in [RFC3477] K. Kompella, Y. Rekther, "Signalling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", work in progress. (RSVP-TE)", work in progress.
[RFC4461] S. Yasukawa, Editor "Signaling Requirements for
Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461.
[RECOVERY] "GMPLS Based Segment Recovery", [RECOVERY] "GMPLS Based Segment Recovery",
draft-ietf-ccamp-gmpls-segment-recovery-02.txt draft-ietf-ccamp-gmpls-segment-recovery-03.txt
23.2. Informative References 23.2. Informative References
[RFC4461] S. Yasukawa, Editor "Signaling Requirements for
Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461.
[BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection", [BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-05.txt, work in progress. draft-ietf-bfd-base-05.txt, work in progress.
[BFD-MPLS] R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "BFD for [BFD-MPLS] R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "BFD for
MPLS LSPs", draft-ietf-bfd-mpls-02.txt, work in progress. MPLS LSPs", draft-ietf-bfd-mpls-02.txt, work in progress.
[LSP-STITCH] A. Ayyanger, J.P. Vasseur, "Label Switched Path [LSP-STITCH] A. Ayyanger, J.P. Vasseur, "Label Switched Path
Stitching with Generalized MPLS Traffic Engineering", Stitching with Generalized MPLS Traffic Engineering",
work in progress work in progress
skipping to change at page 54, line 42 skipping to change at page 54, line 42
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
27. Full Copyright Statement 27. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 23 change blocks. 
38 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/