< draft-leroux-ccamp-ctrl-saturation-00.txt   draft-leroux-ccamp-ctrl-saturation-01.txt >
CCAMP Working Group JL Le Roux Internet Working Group J.-L. Le Roux
Internet Draft JY Mazeas Internet Draft J.-Y. Mazeas
France Telecom Proposed Category: Standard Track France Telecom
JP Vasseur Expires: January 2006 J.-P. Vasseur
Sami Boutros S. Boutros
Cisco Systems Cisco Systems
D. Papadimitriou
Alcatel
Category: Standard Track July 2005
Expires: July 2005 February 2005
Procedure to handle (G)MPLS-TE control plane saturation Procedure to handle (G)MPLS-TE control plane saturation
draft-leroux-ccamp-ctrl-saturation-00.txt draft-leroux-ccamp-ctrl-saturation-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or IPR claims of which I am aware have been disclosed, or will applicable patent or other IPR claims of which he or she is aware
be disclosed, and any of which I become aware will be disclosed, in have been or will be disclosed, and any of which he or she becomes
accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
skipping to change at page 2, line 9 skipping to change at page 2, line 9
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines extensions to RSVP-TE (Resource Reservation This document defines extensions to RSVP-TE (Resource Reservation
Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to
signal control plane resources saturation, when an LSR runs out of notify about control plane resources saturation, when an LSR runs out
control plane resources available to support a new LSP. Such of control plane resources available to support any additional LSP.
notification may serve as trigger for the impacted Head-end LSR to Such notification may serve as trigger for the impacted Head-end LSR
take appropriate actions. to take appropriate actions.
Table of Contents Table of Contents
1. Introduction................................................3 1. Terminology.................................................2
2. Terminology.................................................4 2. Introduction................................................3
3. RSVP-TE Saturation..........................................4 3. RSVP-TE Saturation..........................................4
4. Signalling extensions.......................................5 4. Signalling extensions.......................................4
4.1. New RSVP Error Code.........................................5 4.1. New RSVP Error Code.........................................4
4.2. Mode of operations..........................................5 4.2. Mode of operations..........................................5
4.2.1. Procedures for a saturated LSR (Transit or Tail)............5 4.2.1. Procedures for a saturated LSR..............................5
4.2.2. Procedures for a Head-End LSR...............................5 4.2.2. Procedures for a Head-End LSR...............................5
5. Routing extensions..........................................6 5. Routing extensions..........................................5
5.1. Encoding of the Saturation TLV..............................6 5.1. Encoding of the Saturation TLV..............................5
5.2. Elements of procedure.......................................7 5.2. Elements of procedure.......................................6
6. Security Considerations.....................................7 5.2.1. Procedures for a Saturated LSR..............................7
7. Acknowledgements............................................7 5.2.2. Procedures for a Head-End LSR...............................7
8. Intellectual Property Statement.............................7 6. Inter-Provider considerations...............................7
8.1. IPR Disclosure Acknowledgement..............................8 7. Security Considerations.....................................8
9. References.................................................8 8. Acknowledgements............................................8
9. References..................................................8
9.1. Normative references........................................8 9.1. Normative references........................................8
9.2. Informative references......................................9 9.2. Informative references......................................8
10. Authors' Address:...........................................9 10. Authors' Address:...........................................9
11. Intellectual Property Statement.............................9
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119. document are to be interpreted as described in RFC-2119.
1. Introduction 1. Terminology
LSR: Label Switching Router
TE-LSP: MPLS Traffic Engineering Label Switched Path
Head-End LSR: Head of a TE-LSP
Tail-End LSR: Tail of a TE-LSP
PSB: RSVP Path State Block
RSB: RSVP Reservation State Block
RSVP-TE Saturation: State of an LSR that cannot accept any new TE-LSP
due to configured thresholds, or control plane limitations
ASBR: Autonomous System Border Router
2. Introduction
Many service providers have deployed RSVP-TE [RFC3209] to setup TE- Many service providers have deployed RSVP-TE [RFC3209] to setup TE-
LSPs and achieve Traffic Engineering objectives. LSPs and achieve Traffic Engineering objectives.
In some circumstances, MPLS-TE deployments in large networks may In some circumstances, MPLS-TE deployments in large networks may
require maintaining a high number of TE-LSPs on transit LSRs and thus require maintaining a high number of TE-LSPs on transit LSRs, which
instantiating a high number of RSVP states, and consuming a large may lead to the instantiation of a high number of RSVP states and
amount of LSR resources such as memory and CPU. hence consume a large amount of LSR control plane resources (e.g.
memory, CPU).
Control plane capacities of an LSR (such as CPU or memory) are of Control plane capacities of an LSR are of course not infinite and
course not infinite, and there may be some circumstances whereby an there may be some circumstances whereby an LSR may run out of a
LSR may run out of a specific resource such as memory or CPU specific control plane resource such as memory or CPU available for
available for the RSVP process; such resource shortage may lead to the RSVP process; such resource shortage may lead to the inability
the inability for the LSR to support signalling of new LSPs. For for the LSR to handle additional TE-LSPs. For instance, the LSR has
instance, the LSR has no longer enough memory to instantiate a new no longer enough memory to instantiate a new RSVP state block (PSB,
RSVP state block (PSB, RSB [RFC2209]), and thus cannot maintain a new RSB [RFC2209]).
LSP. In such situation, the saturated LSR should properly reject the
LSP setup, and notify the head-end LSR about its saturation.
Note that it may also be useful to allow the operator to limit (by Furthermore, there may be circumstances whereby the operator may want
configuration) the maximum number of RSVP-TE sessions that can be to limit, by configuration, the maximum number of RSVP-TE sessions
maintained by an LSR, at Ingress, Transit or Egress. that can be accepted and maintained by an LSR at the Ingress, Transit
This allows controlling the impact of RSVP-TE on other control plane or Egress position.
entities.
This document defines a particular state for an RSVP node, called the This document defines a particular RSVP-TE state (referred to as the
"Saturated" state. An RSVP node is said saturated, when it cannot "Saturated" state) whereby the LSR cannot handle any additional TE-
support an additional TE-LSP, either because the maximum number of LSP, either because the maximum number of TE-LSPs allowed is reached
RSVP sessions configured by the operator is reached or because there or because there is no longer enough control plane resources (CPU,
is no longer enough resources (CPU, memory,à) allocated to the RSVP memory,à) allocated to the RSVP process to instantiate and maintain a
process, to instantiate and maintain a new session state block. There new session state block.
may be cases, particularly in large scale RSVP-TE deployments, where
an LSR receives a Path message for a new LSP, while it is saturated.
This document specifies: There may be cases, particularly in large scale RSVP-TE deployments,
- a RSVP-TE extension allowing a saturated RSVP node to reject any where an LSR receives a Path message for a new LSP, while it is under
new LSP and notify (using a new Error code and a set of sub-codes the Saturated state. In such situation, the LSR should simply reject
carried in a Path Error message) the head-end LSR about its the LSP setup, and notify the head-end LSR of its control plane
saturation. saturation state.
- IGP extensions (that complement the RSVP-TE extension) in order for
a LSR to advertise its current saturation state (saturated or not).
This allows head-end LSRs avoiding the set up of new TE LSP through
saturated nodes and also allows reoptimizing TE-LSPs when a given
node is no longer saturated.
2. Terminology For that purpose, this document specifies:
LSR: Label Switching Router - A RSVP-TE extension allowing a saturated LSR to reject any new LSP
and notify (using a new Error code and a set of sub-codes carried
in a Path Error message) the head-end LSR about its saturation;
TE-LSP: MPLS Traffic Engineering Label Switched Path - IGP extensions (that complement the RSVP-TE extension) in order
for a LSR to advertise its current saturation status (saturated or
not). This allows other head-end LSRs avoiding the set up of new
TE LSP through saturated nodes and also discovering that a given
node is no longer saturated.
RSVP-TE Saturation: State of an LSR that cannot accept any new TE-LSP These routing and signalling notifications are complementary. They
due to control plane limitations may serve as trigger for the Head-End LSRs to take appropriate
actions.
3. RSVP-TE Saturation 3. RSVP-TE Saturation
Some RSVP-TE deployment scenarios may generate a high number of RSVP A RSVP-TE engine is usually designed such that the maximum number of
sessions on transit LSRs, and consume a significant amount of LSPs it supports equals the total number of LSP with a resource
resources (such as memory and CPU). Depending on LSR control plane allocation corresponding to the min LSP bandwidth (set e.g. to 2
capacities, there may be cases where an LSR is not able to support Mbps) configured in the context of its admission control mechanism.
any new TE LSPs for a specific amount of time. Of course, note that However, soft-provisioning techniques (e.g. LSP established with no
such state may be transitional and this document proposes mechanism bandwidth reservation) are challenging this rule of thumb since the
to signal that the node is no longer in such state by means of number of supported LSPs needs now to take not only data plane
routing extensions. resources allocation into account but also control plane resources.
An RSVP node enters the saturated state when it runs out of a
specific resource such as the memory or CPU (globally or for the RSVP
process) or some other constraints are reached (for the sake of
illustration, this can be the number of transiting LSPs which can
influence the rerouting time in case of failure with some network
recovery techniques).
A saturated LSR MUST reject the setup of a new TE-LSP, and SHOULD An RSVP node enters the Saturated state when it runs out of specific
maintain already established TE-LSPs. control plane resource such as the memory or CPU (globally or for the
RSVP process) or above a pre-configured threshold or when a pre-
configured maximum number of LSPs allowed is reached. Criteria to
trigger such saturated state are local to the LSR and outside of the
scope of this document.
Note that it is recommended to introduce some hysteresis for Note that it is recommended to introduce some hysteresis for
saturation state transition, in order to avoid oscillations. saturation state transition, so as to avoid oscillations.
For instance in case the number of TE-LSPs is bounded, two thresholds For instance if the number of TE-LSPs is bounded (by configuration),
could be configured: two thresholds should be configured: An upper-threshold and a lower-
The upper-threshold: An LSR enters the saturated when the number threshold with upper-threshold > lower-threshold. An LSR enters the
of TE-LSPs reaches the upper-threshold. saturated state when the number of TE-LSPs reaches the upper-
The lower-threshold: An LSR leaves the saturated state when the threshold and leaves the saturated state when it goes down the lower-
number of TE-LSPs goes below the lower-threshold. threshold.
4. Signalling extensions 4. Signalling extensions
4.1. New RSVP Error Code 4.1. New RSVP Error Code
This document specifies a new Error Code (suggested value This document specifies a new Error Code (suggested value
to be confirmed by IANA) for the RSVP ERROR_SPEC object: to be confirmed by IANA) for the RSVP ERROR_SPEC object:
26 Control Plane Saturation 26 Control Plane Saturation
The following defines error values sub-codes for the new Control The following defines error values sub-codes for the new Control
Plane Saturation Error Code: Plane Saturation Error Code:
1 Saturation unspecified 1 Saturation unspecified
2 Memory saturation 2 Memory saturation
3 CPU saturation 3 CPU saturation
4 Max number of LSPs reached
100-255 Proprietary 100-255 Reserved
Procedures are detailed in section 4.2 below. Procedures are detailed in section 4.2 below.
4.2. Mode of operations 4.2. Mode of operations
4.2.1. Procedures for a saturated LSR (Transit or Tail) 4.2.1. Procedures for a saturated LSR
On receipt of a Path message for a new LSP, a saturated LSR compliant On receipt of a Path message for a new LSP, a saturated LSR compliant
with this document MUST reject the LSP setup and send back a Path with this document SHOULD reject the LSP setup and send back a
Error Message with the Error Code "Saturation" and optionally a sub- PathErr Message with the Path_State_Removed flag set in the
code mentioning the reasons for the saturation. ERROR_SPEC object, with the Error Code "Saturation" and optionally an
Error sub-code value mentioning the reasons for the saturation.
The Error node address carried within the ERROR_SPEC object MUST be
set to the TE router id.
4.2.2. Procedures for a Head-End LSR The address carried within the ERROR_SPEC object SHOULD be set to the
TE router id of the saturated node. The IF_ID ERROR_SPEC object MAY
be used in case saturation can be determined as coming from a given
adjacency.
On receipt of a Path Error message with the Error Code "Saturation" To avoid inability of the saturated node to generate PathErr
and with the PSR flag not set, the Head-End LSR SHOULD send a Path messages, it is expected that the locally pre-configured threshold on
Tear message for the LSP. control plane resources is such that it allows generation of such
messages.
The head-end LSR should trigger the computation of a new path 4.2.2. Procedures for a Head-End LSR
avoiding the saturated node, and it may also choose to avoid the
saturated node for future LSPs. An implementation may decide to
signal some of its TE LSPs along the saturated node upon the
expiration of some timer.
The head-end should not reroute already established LSPs passing On receipt of a PathErr message with the Error Code "Saturation" and
through the saturated node. with the Path_State_Removed flag not set, the Head-End LSR SHOULD
send a PathTear message for the rejected LSP.
5. Routing extensions 5. Routing extensions
It is obviously desirable to augment the signaling extensions by It is desirable to augment the signaling extensions by specific link
routing notifications ([ISIS-TE], [OSPF-TE]) that would allow an LSR state routing ([ISIS] and [OSPF]) extensions that would allow an LSR
to advertise the state of its RSVP process (saturated or not). This to advertise the state of its RSVP process (saturated or not). This
information could then be taken into account by all LSRs (and not information could then be taken into account by all LSRs (and not
only LSRs on the path of a rejected LSPs), in order to avoid a only LSRs on the path of a rejected LSPs), in order to avoid a
saturated node when computing the path of a new TE-LSP, and also to saturated node when computing the path of a new TE-LSP, and also to
automatically discover when a node is no longer saturated and automatically discover when a node is no longer saturated.
potentially trigger appropriate TE-LSP reoptimisation.
A new TLV is defined for OSPF and ISIS, named the ôSaturation TLVö, A new TLV is defined for OSPF and ISIS, named the ôSaturation TLVö,
to be included in the Router Information LSA for OSPF [OSPF-CAP] and to be included in the Router Information LSA for OSPF [OSPF-CAP] and
in the CAPABILITY TLV for ISIS [ISIS-CAP]. in the CAPABILITY TLV for ISIS [ISIS-CAP].
This TLV contains a set of 32 bit flags. Currently only one flag is The TLV structure consists of a fixed 8 bit flags field. Currently 4
defined, to indicate if the LSR is saturated or not. flags are defined, to indicate if the LSR is saturated or not as well
as the reasons for the saturation.
5.1. Encoding of the Saturation TLV 5.1. Encoding of the Saturation TLV
This document defines a new TLV, the Saturation TLV, allowing an LSR This document defines a new TLV (named the Saturation TLV) allowing
advertising if its control plane is saturated or not, where, an LSR advertising if its control plane is saturated or not, where,
-With OSPF, the Saturation TLV is a TLV of the Router Information - With OSPF, the Saturation TLV is a TLV of the Router Information
LSA defined in [OSPF-CAP], and its TLV type is TBD. LSA defined in [OSPF-CAP]. The TLV type is TBD (To be assigned
-With ISIS, the Saturation TLV is a sub-TLV of the ISIS CAPABILITY by IANA).
TLV defined in [ISIS-CAP], and its sub-TLV type is TBD. - With ISIS, the Saturation TLV is a sub-TLV of the ISIS
CAPABILITY TLV defined in [ISIS-CAP]. The sub-TLV type is TBD
(To be assigned by IANA).
All relevant generic TLV encoding rules (including TLV format, All relevant generic TLV encoding rules (including TLV format,
padding and alignment, as well as IEEE floating point format padding and alignment, as well as IEEE floating point format
encoding) defined in [OSPF] and [ISIS] are applicable to this new encoding) defined in [OSPF] and [ISIS] are applicable to this new
sub-TLV. sub-TLV.
The Saturation TLV is a series of 32 bit flags. Its format is The Saturation TLV is a series of 8 bit flags. Its format is
illustrated below: illustrated below:
0 1 2 3 0 1 2 3 4 5 6 7
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 +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|C|M|N| Res |
|S| Reserved | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Four bits are currently defined:
Only one bit is currently defined:
-S bit: When set this indicates that the node is saturated and -S bit: When set this indicates that the node is saturated and
cannot support new TE-LSPs. When not set this indicates that the node cannot support any new TE-LSP. When not set this
is not saturated and can support new TE-LSPs. indicates that the node is not saturated and can support
new TE-LSPs.
-C bit: When set this indicates that the saturation is due to
CPU overload.
-M bit: When set this indicates that the saturation is due to
memory shortage .
-N bit: When set this indicates that the maximum number of LSPs
allowed is reached.
New flags may be defined in the future to indicate the reasons for C, M or N are not exclusive. They can be set only if S is set.
the saturation. If S is set and other flags are cleared this means that the reason
for the saturation is unspecified.
Note that new flags may be defined in the future.
The absence of the saturation TLV means that the saturation status is
unspecified.
5.2. Elements of procedure 5.2. Elements of procedure
A router MUST originate a new IS-IS LSP/OSPF LSA whenever a A router SHOULD originate a new IS-IS LSP/OSPF LSA whenever a
saturation state change occurs or whenever required by the saturation state change occurs or whenever required by the
regular IS-IS/OSPF procedure (LSP/LSA refresh). regular IS-IS/OSPF procedure (LSP/LSA refresh).
It is expected that a proper implementation will support dampening
algorithms so as to dampen IGP flooding, thus preserving the IGP
scalability.
A saturated node MUST originate LSPs/LSAs with the S bit of the The flooding scope of this saturation state advertisement SHOULD be
Saturation TLV set. limited to a single IGP area. This implies that this TLV SHOULD be
carried within an OSPF type 10 Router Information LSAs or within an
ISIS CAPIBILITY TLV with the S flag cleared.
Note that a head-end LSR computing a path of a TE-LSP should avoid Note that a saturation satus change MAY trigger CSPF computation, but
saturated nodes. Note also that when a head-end LSR detects that a MUST not trigger normal SPF computation.
node on the path of an already established TE-LSP, becomes saturated,
it should not reroute this TE-LSP.
Once an LSR leaves the saturation state, the condition of which are 5.2.1. Procedures for a Saturated LSR
implementation specific, it MUST originate LSPs/LSAs with the S bit
of the Saturation TLV cleared. An implementation may decide to
originate an LSP/LSP with the S bit of its Saturation TLV cleared for
a configurable amount of time and then decide not to include the
saturation TLV in its LSA/LSP.
Note that when a head-End LSR detects that an LSR is no longer Once an LSR enters the saturation state, the conditions of which are
saturated it may try to reoptimize TE-LSPs, should the path along the implementation specific, it SHOULD originate LSPs/LSAs with the S bit
no-longer saturated node be optimal. This procedure may be delayed, of the Saturation TLV set and potentially with one or more "reason"
potentially using some LSP setup jittering between head-end LSRs, in bits set.
order to avoid a signalling storm that may again saturate the node,
that is, to avoid TE-LSP routing oscillations.
6. Security Considerations Once a LSR leaves the saturation state, the conditions of which are
implementation specific, it SHOULD originate LSPs/LSAs with all bits
of the Saturation TLV cleared.
This document does not raise any new security issue. 5.2.2. Procedures for a Head-End LSR
7. Acknowledgements A head-end LSR computing a path of a TE-LSP should avoid saturated
nodes.
We would like to thank Thomas Morin and Bruno Decraene for the really Note also that when a head-end LSR detects that a node on the path of
useful comments and suggestions, and Muthurajah Sivabalan, Rudy an already established TE-LSP, becomes saturated, it should not
Figaro, David Ward, Reshad Rahman, and Stefano Previdi for their reroute this TE-LSP.
input and contributions to the IGP extensions.
8. Intellectual Property Statement Note that when a head-End LSR detects that an LSR is no longer
saturated it may re-use this LSR for establishing new TE LSPs, and
may try to reoptimize some TE-LSPs, should the path along the no-
longer saturated LSR be desirable.
This procedure may be delayed, potentially using some LSP setup
jittering between head-end LSRs, in order to avoid a signalling storm
that may again saturate the node, that is, to avoid TE-LSP routing
oscillations.
The IETF takes no position regarding the validity or scope of any Note that the procedures discussed above are local implementation
Intellectual Property Rights or other rights that might be claimed to issues.
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 6. Inter-Provider considerations
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 For confidentially purpose in an inter-provider MPLS-TE context (see
copyrights, patents or patent applications, or other proprietary [INTER-AS-REQ]), a provider may desire to hide to other providers, a
rights that may cover technology that may be required to implement saturation that could occur in its own network. For that purpose an
this standard. Please address the information to the IETF at ietf- ASBR may modify the RSVP error code/sub-code before forwarding the
ipr@ietf.org. PathErr message to an upstream provider. For instance, if a provider
wants to hide the reason for the saturation, it should update the
error sub-code to 1. If the provider wants to entirely hide the
saturation, it may change the error code. Note that this is a local
policy-based decision.
8.1. IPR Disclosure Acknowledgement 7. Security Considerations
By submitting this Internet-Draft, I certify that any applicable This document does not raise any new security issue.
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be 8. Acknowledgements
disclosed, in accordance with RFC 3668.
We would like to thank Thomas Morin, Bruno Decraene, Adrian Farrel,
Arthi Ayyangar, Muthurajah Sivabalan, Rudy Figaro, David Ward, Reshad
Rahman, and Stefano Previdi for the really useful comments and
suggestions.
9. References 9. References
9.1. Normative references 9.1. Normative references
[RFC] Bradner, S., 'Key words for use in RFCs to indicate [RFC] Bradner, S., 'Key words for use in RFCs to indicate
requirements levels', RFC 2119, March 1997. requirements levels', RFC 2119, March 1997.
[RFC3667] Bradner, S., 'IETF Rights in Contributions', BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., 'Intellectual Property Rights in IETF
Technology', BCP 79, RFC 3668, February 2004.
[TE-REQ] Awduche et. al., 'Requirements for Traffic Engineering [BCP79] Bradner, S., Ed., 'Intellectual Property Rights in IETF
over MPLS', RFC2702. Technology', BCP 79, RFC 3979, March 2005.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
'Resource ReSerVation Protocol (RSVP) -- Version 1, Functional 'Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification', RFC 2205, September 1997. Specification', RFC 2205, September 1997.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, 'RSVP-TE: Extensions
to RSVP for LSP Tunnels', RFC 3209, December 2001.
[RFC2209] Braden, R., Zhang, L., 'Resource ReSerVation Protocol [RFC2209] Braden, R., Zhang, L., 'Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules', RFC2209, (RSVP) -- Version 1 Message Processing Rules', RFC2209, September
September 1997. 1997.
[ISIS] "Intermediate System to Intermediate System Intra-Domain [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T.,
Routing Exchange Protocol " ISO 10589. Srinivasan, V. and G. Swallow, 'RSVP-TE: Extensions to RSVP for LSP
Tunnels', RFC 3209, December 2001.
[ISIS-TE] Smit, H., Li, T., 'Intermediate System to Intermediate [ISIS] "Intermediate System to Intermediate System Intra-Domain
System (IS-IS)Extensions for Traffic Engineering (TE)', Routing Exchange Protocol " ISO 10589.
RFC3784, June 2004
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPF-TE] Katz, D., Kompella, K., Yeung, D., 'Traffic Engineering
(TE) Extensions to OSPF Version 2', RFC3630, September 2003
9.2. Informative references
[ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N. et al. "IS-IS [ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N. et al. "IS-IS
extensions for advertising router information", draft- extensions for advertising router information", draft-ietf-isis-
vasseur-isis-caps-02.txt, work in progress. caps-03.txt, work in progress.
[OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur,
J.P., "Extensions to OSPF for advertising Optional Router J.P., "Extensions to OSPF for advertising Optional Router
Capabilities", draft-ietf-ospf-cap-05.txt, work in progress. Capabilities", draft-ietf-ospf-cap-07.txt, work in progress.
9.2. Informative references
[INTER-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic
Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-
09.txt, work in progress
10. Authors' Address: 10. Authors' Address:
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
jeanlouis.leroux@francetelecom.com jeanlouis.leroux@francetelecom.com
skipping to change at page 10, line 8 skipping to change at page 9, line 34
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Sami Boutros Sami Boutros
Cisco Systems Cisco Systems
2000 Innovation Drive, Kanata, 2000 Innovation Drive, Kanata,
Ontario, Canada K2K 3E8 Ontario, Canada K2K 3E8
sboutros@cisco.com sboutros@cisco.com
Full Copyright Statement Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Email: dimitri.papdimitriou@alcatel.be
Copyright (C) The Internet Society (2005). This document is subject 11. Intellectual Property Statement
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
 End of changes. 69 change blocks. 
224 lines changed or deleted 273 lines changed or added

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