[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item)
Dimitri,
We are planning to sending the enclosed version before the flood gate
closes. The use of link attribute subTLV is stated as completely
optional. Please find the following text in enclosed updated version.
"to deal with nodes not compliant with this document (i.e., does not
implement link attribute sub-TLV based solution), the node initiating
graceful shutdown MAY originate the TE LSA/LSP containing Link TLV with
0 unreserved bandwidth, Traffic Engineering metric set to 0xffffffff,
and if the Link is non-PSC then also with 0 as Max LSP Bandwidth."
Thanks
Regards... Zafar
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali)
> Sent: Sunday, March 05, 2006 1:02 PM
> To: Dimitri.Papadimitriou@alcatel.be
> Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org;
> dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur);
> Kireeti Kompella; owner-ccamp@ops.ietf.org
> Subject: RE: Need to close on signaling solution for graceful
> shutdown (Follow-up on our Action Item)
>
> Hi Dimitri,
>
> There is a difference between expected operations in graceful
> restart and graceful shutdown; hence my previous email. The
> draft already lists Max Metric as a possible solution with
> motivation for selecting link attribute based solution. If
> the WG agrees that use of Max Metric suffices, we can fall
> back to the use of the Max Metric/ zero bw. We will be
> posting an updated version later tonight.
>
> Thanks
>
> Regards... Zafar
>
> > -----Original Message-----
> > From: Dimitri.Papadimitriou@alcatel.be
> > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > Sent: Friday, March 03, 2006 6:46 PM
> > To: Zafar Ali (zali)
> > Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org;
> > dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur); Kireeti
> > Kompella; owner-ccamp@ops.ietf.org
> > Subject: RE: Need to close on signaling solution for
> graceful shutdown
> > (Follow-up on our Action Item)
> >
> > hi zafar
> >
> > then i will express my concern in the other way around
> concerning the
> > "routing" part of this document: we have clean procedures
> for planned
> > node restart in RFC4203; hence, the reason for having a "cleaner"
> > procedure is totally unclear to me both in terms of motivation and
> > applicability
> >
> > much thanks,
> > - dimitri.
> >
> >
> >
> >
> >
> >
> >
> >
> > "Zafar Ali \(zali\)" <zali@cisco.com>
> > Sent by: owner-ccamp@ops.ietf.org
> > 02/03/2006 07:06
> >
> > To: <dpapadimitriou@psg.com>, Dimitri
> > PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > cc: <ccamp@ops.ietf.org>, "Adrian Farrel"
> > <adrian@olddog.co.uk>, "Anca Zamfir \(ancaz\)"
> > <ancaz@cisco.com>, "Jean Philippe Vasseur \(jvasseur\)"
> > <jvasseur@cisco.com>, "Kireeti Kompella"
> > <kireeti@juniper.net>
> > Subject: RE: Need to close on signaling solution for
> > graceful shutdown (Follow-up on our Action Item)
> >
> >
> > Hi Dimitri,
> >
> > Sorry for the delay in replying. Please see reply in-line.
> >
> > All,
> >
> > I am assuming the WG is ok with the signaling part of the
> solution. If
> > you have any comments, please reply to my original email.
> We plan to
> > refresh the ID before the flood gate closes.
> >
> > Thanks
> >
> > Regards... Zafar
> >
> > > -----Original Message-----
> > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
> > > Sent: Monday, February 20, 2006 2:01 AM
> > > To: Zafar Ali (zali)
> > > Cc: ccamp@ops.ietf.org; Adrian Farrel; Anca Zamfir (ancaz); Jean
> > > Philippe Vasseur (jvasseur); Kireeti Kompella
> > > Subject: Re: Need to close on signaling solution for graceful
> > > shutdown (Follow-up on our Action Item)
> > >
> > >
> > > zafar - thanks for the summary ... but i don't understand the
> > > following sentence
> > >
> > > "The IGP based solution is also based on an existing framework."
> > >
> > > to which framework are you referring to ?
> > >
> > > i am more concerned with section 4.2, for three reasons
> > >
> > > o) the document seems to say that such links could be
> used as last
> > > resort link for zero bandwidth LSP - note that this
> applies only to
> > > PSC links because non-PSC would not make use of such
> links - let's
> > > assume this may be the case, as you are dealing with a "planned
> > > outage" i am not sure you are going to make a lot of
> operations such
> > > as new path computations during such event (and risk further
> > > degradation)
> > >
> >
> > A link may end-up with max metric for multiple reasons and
> without the
> > link attribute there is no way a node can tell what the reason is,
> > e.g.
> > a restarting node may advertises the max matrices.
> Furthermore, if the
> > resource under graceful deletion is the last resort then the node
> > hosting the graceful deletion resource will not receive new
> signaling
> > messages. Also, graceful deletion is not the main
> motivation for the
> > introduction of the link attribute sub-TLV; we are just overloading
> > the use of link attribute to provide a cleaner
> specification. Hence, I
> > mention "existing framework". We can enhance the text in
> the ID to be
> > more specific in this notification.
> >
> > > o) the document makes use of a link attribute (but where is this
> > > attribute defined ?)
> > >
> >
> > The link attribute ID-es needs to be refreshed.
> >
> > > o) this section forces to have to have two different
> procedures (as
> > > planned restarting nodes advertise their link with these
> attributes
> > > making them unusable before the restart occurs, section 2 of
> > > RFC4203)
> > >
> >
> > See my comment above.
> >
> > > thanks,
> > > - dimitri.
> > >
> > >
> > > Zafar Ali (zali) wrote:
> > >
> > > > Dear Ccampers:
> > > >
> > > >
> > > >
> > > > This is a follow-up on our action item from the last IETF
> > > meeting to
> > > > send an email to close the signaling solution for
> > graceful shutdown
> > > > procedure proposed in
> > > >
> > >
> >
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut
> > > > do
> > > > wn-02.txt
> > > >
> > >
> >
> <http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shu
> > > > td
> > > > own-02.txt> .
> > > >
> > > >
> > > >
> > > > During the meeting it was clear that we have an
> agreement on the
> > > > requirement front. We also have an agreement that we need
> > > both routing
> > > > and signaling based solutions. This is because an IGP
> only based
> > > > solution is not applicable when dealing with Inter-area and
> > > Inter-AS
> > > > traffic engineering, as LSA or LSP flooding is
> restricted to IGP
> > > > areas/levels. Consequently, RSVP based mechanisms are
> > > required to cope
> > > > with TE LSPs spanning multiple domains. The draft presents
> > > > complementary mechanisms for RSVP-TE and IGP for Graceful
> > Shutdown.
> > > > The IGP based solution is also based on an existing
> > framework. Our
> > > > action item is to close on the signaling based counterpart.
> > > >
> > > >
> > > >
> > > > Before we compare the candidate solution, let's discuss and
> > > agree on
> > > > general requirement for a signaling based graceful shutdown
> > > mechanism.
> > > > In graceful shutdown procedure, as the Ingress LSR is
> expected to
> > > > perform make-before-break for the LSP (using the
> resource that is
> > > > being shutdown), we should be able to specify the TE
> > > resource (link/
> > > > node) under graceful shutdown. Furthermore, conveying
> signaling
> > > > message to the Ingress LSR suffices. I.e., we can make use
> > > of the Notify Message.
> > > >
> > > >
> > > >
> > > > One of the solutions proposed during these discussions is
> > > to make use
> > > > of the admin status object. However, admin status
> cannot contain
> > > > information about TE resource under Graceful Shutdown.
> > > Hence, we did
> > > > not consider use of admin status object as a possible solution.
> > > >
> > > >
> > > >
> > > > Another alternate that was put forward is the use ALARM_
> > > SPEC Objects.
> > > > While ALARM_ SPEC Objects has ability to Signal Info about
> > > TE resource
> > > > under Graceful shutdown, use of this object in the notify
> > > message is
> > > > not defined. We also feel use of the ALARM_ SPEC Objects is
> > > heavy duty
> > > > for signaling simple Graceful Shutdown condition.
> > > >
> > > >
> > > >
> > > > We propose to overload "TE link maintenance required"
> > > sub-code of the
> > > > Notify Error Code (24) of the ERROR_SPEC. We believe
> this is the
> > > > simplest solution with existing/ well used way to signal
> > > information
> > > > about TE resource under Graceful Shutdown. Furthermore, the
> > > ERROR_SPEC
> > > > with code 24/ sub-code TBD can then be carried in either
> > PathErr or
> > > > Notify message to signal graceful condition.
> > > >
> > > >
> > > >
> > > > Can you please send your comments to this by the end of
> > > this week so
> > > > we can update the ID, if needed?
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> > > > Regards... Zafar
> > > >
> > > > This is a follow-up on our action item from the last IETF
> > > meeting to
> > > > send an email to close the signaling solution for
> > graceful shutdown
> > > > procedure proposed in
> > > >
> > >
> >
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut
> > > > do
> > > > wn-02.txt.
> > > >
> > > >
> > > >
> > > > During the meeting it was clear that we have an
> agreement on the
> > > > requirement front. We also have an agreement that we need
> > > both routing
> > > > and signaling based solutions. This is because an IGP
> only based
> > > > solution is not applicable when dealing with Inter-area and
> > > Inter-AS
> > > > traffic engineering, as LSA or LSP flooding is
> restricted to IGP
> > > > areas/levels. Consequently, RSVP based mechanisms are
> > > required to cope
> > > > with TE LSPs spanning multiple domains. The draft presents
> > > > complementary mechanisms for RSVP-TE and IGP for Graceful
> > Shutdown.
> > > > The IGP based solution is also based on an existing
> > framework. Our
> > > > action item is to close on the signaling based counterpart.
> > > >
> > > >
> > > >
> > > > Before we compare the candidate solution, let's discuss and
> > > agree on
> > > > general requirement for a signaling based graceful shutdown
> > > mechanism.
> > > > In graceful shutdown procedure, as the Ingress LSR is
> expected to
> > > > perform make-before-break for the LSP (using the
> resource that is
> > > > being shutdown), we should be able to specify the TE
> > > resource (link/
> > > > node) under graceful shutdown. Furthermore, conveying
> signaling
> > > > message to the Ingress LSR suffices. I.e., we can make use
> > > of the Notify Message.
> > > >
> > > >
> > > >
> > > > One of the solutions proposed during these discussions is
> > > to make use
> > > > of the admin status object. However, admin status
> cannot contain
> > > > information about TE resource under Graceful Shutdown.
> > > Hence, we did
> > > > not consider use of admin status object as a possible solution.
> > > >
> > > >
> > > >
> > > > Another alternate that was put forward is the use ALARM_
> > > SPEC Objects.
> > > > While ALARM_ SPEC Objects has ability to Signal Info about
> > > TE resource
> > > > under Graceful shutdown, use of this object in the notify
> > > message is
> > > > not defined. We also feel use of the ALARM_ SPEC Objects is
> > > heavy duty
> > > > for signaling simple Graceful Shutdown condition.
> > > >
> > > >
> > > >
> > > > We propose to overload "TE link maintenance required"
> > > sub-code of the
> > > > Notify Error Code (24) of the ERROR_SPEC. We believe
> this is the
> > > > simplest solution with existing/ well used way to signal
> > > information
> > > > about TE resource under Graceful Shutdown. Furthermore, the
> > > ERROR_SPEC
> > > > with code 24/ sub-code TBD can then be carried in either
> > PathErr or
> > > > Notify message to signal graceful condition.
> > > >
> > > >
> > > >
> > > > Can you please send your comments to this by the end of
> > > this week so
> > > > we can update the ID, if needed?
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> > > > Regards... Zafar
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>
CCAMP Working Group
Zafar Ali
Jean Philippe Vasseur
Anca Zamfir
Cisco Systems, Inc.
IETF Internet Draft
Category: Standard track
Expires: September 2006
March 2006
draft-ali-ccamp-mpls-graceful-shutdown-03.txt
Graceful Shutdown in GMPLS Traffic Engineering Networks
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 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.
[Page 1]
Abstract
GMPLS-TE Graceful shutdown is a method for explicitly notifying the
nodes in a TE network that the TE protocol on a link or on an entire
TE node is going to be disabled. GMPLS-TE graceful shutdown
mechanisms are tailored towards addressing the planned outage in the
network.
This document provides requirements and protocol mechanisms so as to
reduce/eliminate traffic disruption in the event of a planned
shutdown of a network resource. These operations are equally
applicable for both classical MPLS and its GMPLS extensions.
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 [i].
Table of Contents
1. Terminology........................................................2
2. Introduction.......................................................3
3. Requirements for Graceful Shutdown.................................3
4. Mechanisms for Graceful Shutdown...................................4
4.1 RSVP-TE Signaling Mechanism for graceful shutdown...............4
4.1.1 Graceful Shutdown of TE link(s)...............................4
4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link...5
4.1.3 Graceful Shutdown of TE Node..................................5
4.2 OSPF/ ISIS Mechanisms for graceful shutdown.....................5
4.2.1 Graceful Shutdown of TE link(s)...............................6
4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link...6
4.2.3 Graceful Shutdown of TE Node..................................6
5. Security Considerations............................................7
6. IANA Considerations................................................7
7. Intellectual Property Considerations...............................7
8. Full Copyright Statement...........................................7
9. Acknowledgments....................................................7
10. Reference.........................................................8
10.1 Normative Reference............................................8
10.2 Informative Reference..........................................8
1.
Terminology
Node - Label Switching Device.
LSP - An MPLS Label Switched Path
Head-end or Ingress node: In the draft term head-end node equally
applies to the Ingress node that initiated signaling for the Path, or
[Page 2]
an intermediate node (in the case of loose hops path computation) or
a Path Computation Element (PCE) that computes the routes on behalf
of its clients (PCC).
GMPLS -
- The term GMPLS is used in this document to refer to both
classic MPLS, as well as the GMPLS extensions to MPLS.
TE Link -
- The term TE link refers to a physical link or an FA-LSP, on
which traffic engineering is enabled. A TE link can be bundled or
unbundled.
2.
Introduction
When outages in a network are planned, some mechanisms can be used to
avoid traffic disruption. This is in contrast with unplanned network
element failure, where traffic disruption can be reduced but may not
avoided. Hence, a Service Provider may desire to gracefully
(temporarily or definitely) disable Traffic Engineering on a TE Link,
a group of TE Links or an entire node for administrative reasons such
as link maintenance, software/hardware upgrade at a node or
significant TE configuration changes. In all these cases, the goal is
to minimize impact on the GMPLS Traffic Engineered flows in the
network by bringing down the protocol before the administrative
procedures are started.
Graceful shutdown of a resource may require several steps. These
steps can be broadly divided into two sets: disabling the resource in
the control plane and removing the resource for forwarding. The node
initiating the graceful shutdown condition SHOULD delay the removal
of the resources for forwarding, for some period determined by local
policy. This is to allow control plane to gracefully divert the
traffic away from the resource being gracefully shutdown.
This document describes the mechanisms that can be used to gracefully
shutdown GMPLS Traffic Engineering on a resource. As mentioned
earlier, the graceful shutdown of Traffic Engineering could be
incorporated in the traditional shutdown operation of an interface,
but it is a separate step that is taken before the IGP on the link is
brought down and before the interface is brought down at different
layers. This document only talks applicable for TE node and TE
resources.
3.
Requirements for Graceful Shutdown
This section lists the requirements for graceful shutdown in the
context of GMPLS Traffic Engineering.
- Graceful shutdown must address graceful removal of one TE link, one
component link within a bundled TE link, a set of TE links, a set of
component links or an entire node.
- It is required to prevent other network nodes to use the network
resources that are about to be shutdown, should new TE LSP be set up.
[Page 3]
Similarly it is required to reduce/eliminate traffic disruption on
the LSP-s using the network resources which are about to be shutdown.
- Trigger for the graceful shutdown event is a local matter at the
node initiating the graceful shutdown. Typically, graceful shutdown
is triggered for administrative reasons, such as link maintenance or
software/hardware upgrade at a node.
- Graceful shutdown mechanisms are required to address TE LSPs
spanning multiple domains, as well as intra domain TE LSPs. Here, a
domain is defined as either an IGP area or an Autonomous System
[INTER-AREA-AS].
- Graceful shutdown is equally applicable to GMPLS-TE, as well as
classical MPLS-TE LSPs.
- In order to make rerouting effective, it is required to communicate
information about the TE resource under graceful shutdown.
4.
Mechanisms for Graceful Shutdown
An IGP only based solution is not applicable when dealing with Inter-
area and Inter-AS traffic engineering, as LSA or LSP flooding is
restricted to IGP areas/levels. Consequently, RSVP based mechanisms
are required to cope with TE LSPs spanning multiple domains. At the
same time, as RSVP mechanisms only convey the information for the
transiting LSPs to the router along the upstream Path and not to all
nodes in the network, indication of graceful shutdown via IGP
flooding is required to discourage a node from establishing new LSPs
through the resources being shut-down. In the following sections the
complementary mechanisms for RSVP-TE and IGP for Graceful Shutdown
are described.
4.1
RSVP-TE Signaling Mechanism for graceful shutdown
As discussed in Section 3, one of the requirements for the signaling
mechanism for graceful shutdown is to carry information about the
resource under graceful shutdown. Therefore, the Graceful Shutdown
mechanism outlined in the following section, uses Path Error and
where available, Notify message, in order to achieve this
requirement. These mechanisms are applicable to the existing LSPs.
Setup request for new LSPs over the TE resource being gracefully
shutdown SHOULD be rejected using the existing mechanisms that are
applied when the TE resource is not available.
4.1.1 Graceful Shutdown of TE link(s)
The node where graceful-shutdown of a link or a set of links is
desired MUST trigger a Path Error message with ??local link
maintenance required?? sub-code for all affected LSPs. The ??local TE
link maintenance required?? error code as defined in [PATH-REOPT]. If
available, and where notify requests were included when the LSPs were
[Page 4]
initially setup, Notify message MAY also be used for fast delivery of
this information to the head-end nodes.
When a head-end node receives Path Error (or Notify message) message
with sub-code "Local Maintenance on TE Link required Flag", it SHOULD
immediately trigger a make-before-break procedure. If the LSP is
protected, switchover procedure may be triggered. A head-end node
SHOULD avoid the IP address contained in the PathErr (or Notify
message) when performing path computation for the new LSP.
4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link
MPLS TE Link Bundling draft [BUNDLE] requires that an LSP is pinned
down to component link(s). Hence, when a component link is shut-down,
the LSPs affected by such maintenance action needs to be re-signaled.
Graceful shutdown of a component link in a bundled TE link differs
from graceful shutdown of unbundled TE link or entire bundled TE
link. Specifically, in the former case, when only a subset of
component links and not the entire TE bundled link is being shutdown,
the remaining component links of the TE links may still be able to
admit new LSPs. Consequently a new error sub-code for PathError or
Notify message is needed:
9 (TBA) Local component link maintenance required
Error Sub-code for ??Local component link maintenance required?? is to
be assigned by IANA.
If the last component link is being shut-down, the procedure outlined
in Section 5.1 is used.
When a head-end node receives an RSVP PathError or Notify message
with sub-code "local component link maintenance required?? Flag set,
it SHOULD immediately perform a make-before-break to avoid traffic
loss. The head-end node MAY still use the IP address contained in the
PathErr or Notify message in performing path computation for
rerouting the LSP. This is because, this address is an IP address of
the component link and the flag is an implicit indication that the TE
link may still have capacity to admit new LSPs. However, if the ERO
is computed such that it also provides details of the component link
selection(s) along the Path, the component link selection with IP
address contained in the PathErr or Notify message SHOULD be avoided.
4.1.3 Graceful Shutdown of TE Node
When graceful shutdown at node level is desired, the node in question
follows the procedure specified in the previous section for all TE
Links.
4.2
OSPF/ ISIS Mechanisms for graceful shutdown
[Page 5]
The procedures provided in this section are equally applicable to
OSPF and ISIS.
4.2.1 Graceful Shutdown of TE link(s)
The node where graceful-shutdown of a link is desired MUST originate
the TE LSA/LSP containing link-attribute sub-TLV with ??local
maintenance required?? bit set. The link-attribute sub-TLV defined in
[OSPF-LINK-ATTRI] and [ISIS-LINK-ATTRI].
Extension to link attribute sub-TLV is preferred over the use of
(MAX-METRIC, zero Bandwidth) based solution. This is because a link
may end-up with max metric for multiple reasons and without the link
attribute there is no way a node can tell what the reason is, e.g. a
restarting node may advertises the max matrices. Furthermore, if the
resource under graceful deletion is the last resort then the node
hosting the graceful deletion resource will not receive new signaling
messages. Nonetheless, to deal with nodes not compliant with this
document (i.e., does not implement link attribute sub-TLV based
solution), the node initiating graceful shutdown MAY originate the TE
LSA/LSP containing Link TLV with 0 unreserved bandwidth, Traffic
Engineering metric set to 0xffffffff, and if the Link is non-PSC then
also with 0 as Max LSP Bandwidth.
Neighbors of the node where graceful shutdown procedure is in
progress SHOULD continue to advertise the actual unreserved bandwidth
of the TE links from the neighbors to that node, without any routing
adjacency change.
The nodes receiving link-attribute sub-TLV with graceful shutdown
indication SHOULD mark the link as unusable for further path
computation in both directions.
4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link
If graceful shutdown procedure is performed for a component link
within a TE Link bundle and it is not the last component link
available within the TE link, the link attributes associated with the
TE link are recomputed. If the removal of the component link results
in a significant change event, the TE link is re-flooded with the new
traffic parameters. If the last component link is being shut-down,
the routing procedure outlined in Section 4.2.1 is used.
4.2.3 Graceful Shutdown of TE Node
When graceful shutdown at node level is desired, the node in question
follows the procedure specified in the previous section for all TE
Links.
[Page 6]
5.
Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RSVP] remain
relevant.
6.
IANA Considerations
A new error sub-code for Path Error and Notify message is needed for
??Local component link maintenance required?? flag.
7.
Intellectual Property Considerations
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.
8.
Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except as
set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9.
Acknowledgments
[Page 7]
The authors would like to acknowledge useful comments from David Ward,
Sami Boutros, Adrian Farrel and Dimitri Papadimitriou.
10.
Reference
10.1
Normative Reference
[RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version
1, Functional Specification", RFC 2205, September 1997.
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[RFC3471] Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, RFC 3471, L. Berger, et al, January
2003.
[RFC3473] L. Berger, et al, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473.
[RFC4203] K. Kompella, Y. Rekhter, et al, ??OSPF Extensions in Support
of Generalized MPLS??, draft-ietf-ccamp-ospf-gmpls-extensions-12.txt.
[RFC4205] K. Kompella, Y. Rekhter, et al, ??IS-IS Extensions in
Support of Generalized MPLS??, draft-ietf-isis-gmpls-extensions-
19.txt.
[ISIS-CAP] Jean-Philippe Vasseur, S. Previdi, J. Mabey, and Jean-
Louis Le Roux, ??IS-IS MPLS Traffic Engineering capabilities??, draft-
vasseur-ccamp-isis-te-caps-00.txt.
[OSPF-LINK-ATTRI] work in progress.
[ISIS-LINK_ATTRI] Jean-Philippe Vasseur, S. Previdi, ??Definition of
an IS-IS Link Attribute sub-TLV??, draft-vasseur-isis-link-attr-
00.txt.
[PATH-REOPT] Jean-Philippe Vasseur, and Y. Ikejiri, ??Reoptimization
of MPLS Traffic Engineering loosely routed LSP paths??, draft-ietf-
ccamp-loose-path-reopt-01.txt.
10.2
Informative Reference
[INTER-AREA-AS] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar,
??A Framework for Inter-Domain MPLS Traffic Engineering??, draft-ietf-
ccamp-inter-domain-framework-04.txt.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering", draft-ietf-mpls-bunle-04.txt (work in
progress)
[Page 8]
Authors' Address:
Zafar Ali
Cisco systems, Inc.,
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada.
Email: zali@cisco.com
Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Anca Zamfir
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
Email: ancaz@cisco.com
[Page 9]