CCAMP Working Group Z. Ali (Cisco)
Internet Draft A. Farrel (Old Dog Consulting)
Category: Standards Track D. Papadimitriou (Alcatel)
A. Satyanarayana (Movaz)
A. Zamfir (Cisco)
Expires: November 2004 May 2004
Generalized Multi-Protocol Label Switching (GMPLS) RSVP-TE
signaling using Bundled Traffic Engineering (TE) Links
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document is a companion to the Generalized Multi-Protocol Label
Switching (GMPLS) RSVP-TE signaling. It extends the TLV definitions
of [RFC3471] to provide the means to identify component links of
unnumbered link bundles within the IF_ID_RSVP_HOP and IF_ID
ERROR_SPEC objects. It also defines the extensions to GMPLS RSVP-TE
in support of component link identifiers for explicit resource
control and recording over link bundles.
D.Papadimitriou (Editor) et al. 1
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
1. Motivation
Link bundling introduced in [BUNDLE] is used to improve routing
scalability by reducing the amount of Traffic Engineering related
information that needs to be flooded and handled by an IGP within an
Autonomous System. This is accomplished by aggregating and
abstracting the TE Link resource. GMPLS RSVP-TE [RFC3471, RFC3473]
allows a bundle of Traffic Engineering links (TE links) to be
represented as a single TE link bundle (a.k.a. bundled TE link). The
constituting links of a TE link bundle are referred to as component
TE links or simply component links.
[RFC3477] defines how unnumbered links may be used in RSVP-TE.
[RFC3471] and [RFC3473] define how unnumbered links can be
identified within the IF_ID_RSVP_HOP and IF_ID ERROR_SPEC objects.
Both numbered and unnumbered component link identifiers are
supported. Moreover, [RFC3471] and [RFC3473] define how numbered and
unnumbered component links of numbered TE link bundles may be
identified within the IF_ID_RSVP_HOP and IF_ID ERROR_SPEC objects.
However, there is no provision for identifying component links of
unnumbered TE link bundles within the IF_ID RSVP_HOP and IF_ID
ERROR_SPEC objects. This is required for completeness and to allow
full functionality of GMPLS RSVP-TE. This document extends the TLV
definitions of [RFC3471] to provide the means to identify component
links of unnumbered TE link bundles within the IF_ID_RSVP_HOP and
IF_ID ERROR_SPEC objects.
GMPLS RSVP-TE [RFC3471, RFC3473] recognizes the value of specifying
the link (interface) identifier both during LSP establishment for
out-of-band signaling (IF_ID_RSVP_HOP object), and for error
reporting (IF_ID ERROR_SPEC object). This is achieved using TLVs in
these objects to specify the link (interface) identifier. Both
numbered and unnumbered link (interface) identifiers are supported.
Furthermore, GMPLS RSVP-TE [RFC3471, RFC3473] recognizes the value
of specifying the component link (interface) identifier of a TE link
bundle during LSP establishment (IF_ID_RSVP_HOP object), and for
error reporting (IF_ID ERROR_SPEC object). This is achieved using
TLVs in these objects to specify the component link (interface)
identifier within a TE link (interface) identifier. However, only
numbered and unnumbered component link (interface) identification
within numbered TE link bundles is supported.
In (G)MPLS, resource control and recording is performed by the use
of an explicit route, i.e., EXPLICIT_ROUTE Object (ERO) and
RECORD_ROUTE Object (RRO), respectively. In most scenarios the
complete resource identification is left as a local decision.
However, there are cases when it is desirable for a non-local (e.g.,
LSP Head-end) node to identify completely or partially the LSP
resources. Consequently, Label ERO (EXPLICIT_ROUTE Object) and RRO
(RECORD_ROUTE Object) subobjects are defined in [RFC3473] to support
Explicit Label Control and recording.
When link bundling is used to aggregate multiple component links
into a TE link bundle, the label is not the only resource that needs
D.Papadimitriou (Editor) 2
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
to be identified and recorded. In other words, the TE link bundle
identifier and the label value specified in the ERO/RRO objects are
not enough to completely identify the resource. For the bundled TE
link case, in order to fully specify the resources on a TE link
bundle for a given LSP, the component link identifier needs to be
specified along with the label. In the case of bi-directional LSPs
both upstream and downstream information may be specified.
Therefore, explicit resource control and recording over a TE link
bundle also requires ability to specify a component link within the
TE link bundle.
This document defines extensions to and describes the use of RSVP-TE
[RFC3209], [RFC3471], [RFC3473], and [RFC3477] to specify the
component link identifier for resource recording and explicit
resource control over TE link bundles. Specifically, it defines the
component interface identifier ERO and RRO subobjects to complement
their Label ERO and RRO counterparts. Furthermore, procedures for
processing component interface identifier ERO and RRO subobjects and
how they can co-exist with the Label ERO and RRO subobjects are
specified. The document also addresses identification of numbered
and unnumbered component link (interface) within unnumbered TE link
bundles.
2. 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 [RFC2119].
Moreover, the reader is assumed to be familiar with the terminology
introduced in [GMPLS-ARCH], [RFC3471], [RFC3473], [RFC3477] and
[BUNDLE]. The following abbreviations are used in this document:
3. Unbundled TE Link Identification
TE links need to be identified in ERO, RRO, RSVP_HOP and
ERROR_SPEC objects. When out-of-band signaling is used, [RFC3471]
extends RSVP_HOP and ERROR_SPEC objects, to include TLVs to
completely identify the TE links. These are the IF_ID RSVP_HOP and
IF_ID ERROR_SPEC objects.
A numbered unbundled TE link can be uniquely identified with the
IPv4 address or the IPv6 address of the TE link. There are no
additional formats required to those defined in [RFC3209] to
identify numbered unbundled TE links in ERO and RRO objects. The
IPv4 and IPv6 TLVs defined in [RFC3471] are used with IF_ID
RSVP_HOP and IF_ID ERROR_SPEC objects to identify numbered
unbundled TE links when out-of-band signaling is used.
An unnumbered unbundled TE link can be uniquely identified by the
tuple {IP Address, Interface ID}. [RFC3477] defines the Unnumbered
Interface ID subobject to identify unnumbered unbundled TE links
in ERO and RRO objects. The IF_INDEX TLV defined in [RFC3471] is
used with the IF_ID RSVP_HOP and the IF_ID ERROR_SPEC objects to
D.Papadimitriou (Editor) 3
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
identify unnumbered unbundled TE links when out-of-band signaling
is used.
The following are the TLVs are defined in [RFC3471] to identify
unbundled TE links.
Type Length Format Description
---- ------ --------- -----------
1 8 IPv4 Address IPv4 (Interface address)
2 20 IPv6 Address IPv6 (Interface address)
3 12 Compound IF_INDEX (Interface index)
4. Component and Bundled TE Link Identification
If a TE link bundle is numbered, the tuple {IP Address, Component
ID} is required to uniquely identify a component link in the TE
link bundle. In this case, depending on the origin of value
assigned to the IP Address either the tuple {Router Address,
Component ID} or {TE Link Address, Component ID} is sufficient to
uniquely identify an unnumbered component link in the TE link
bundle. These tuples are respectively of Type 4, 5 and the newly
defined Type 6, 7. [RFC3471] defines the following TLVs for
Component ID identification IF_ID RSVP_HOP and IF_ID ERROR_SPEC
objects.
Type Length Format Description
---- ------ ------ -----------
4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 Compound COMPONENT_IF_UPSTREAM (Component interface)
6 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface)
7 12 Compound COMPONENT_IF_UPSTREAM (Component interface)
If a TE link bundle is unnumbered, the tuple {IP Address, Bundle
ID, Component ID} is required to uniquely identify a component
link in the TE link bundle. In this case, two new TLVs are defined
for use in the IF_ID RSVP_HOP object and in the IF_ID ERROR_SPEC
Object to identify a component link in an unnumbered TE link
bundle. Note that the Type values shown here are only suggested
values - final values are TBD and to be determined by IETF
consensus.
Type Length Format Description
---- ------ ------ -----------
8 16 See below UNUM_COMPONENT_IF_DOWN (Component interface)
9 16 See below UNUM_COMPONENT_IF_UP (Component interface)
The formats of both the TLVs are the same, as defined below. Two
new TLV types are defined. UNUM_COMPONENT_IF_DOWN is used to
identify the downstream component link in an unnumbered TE link
bundle. UNUM_COMPONENT_IF_UP is used to identify the upstream
component link in an unnumbered TE link bundle.
Note: [BUNDLE] and [RFC3477] assumes that identifying component
link suffices to identify (bundle link, component link) for both
D.Papadimitriou (Editor) 4
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
numbered and unnumbered case. I.e., for unnumbered case, both
component link identifiers and TE link identifiers comes from the
same unit32 bit space.
4.1 TLV Definitions
The new TLVs have a common format as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address: 32 bits
Any IP address associated with the local node. This should be an
IP address that has the highest availability on the node. This
may match the Router Address value as advertised in TE LSAs by
routing.
Interface ID: 32 bits
The identifier of the unnumbered bundled link. By definition,
this is unique within the scope of the node identified by the IP
Address field.
Component ID: 32 bits
The identifier of the component link in the unnumbered TE
bundle, uniquely identified by the tuple {IP Address, Interface
ID}. During LSP establishment, the special value 0xFFFFFFFF can
be used to indicate the same label to be valid across all
component links in the bundle identified by the {IP Address,
Interface ID}.
5. Signaling Component TE Links in ERO
A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used
to specify component interface identifier of a bundled TE Link. This
subobject SHOULD NOT be used apart from (explicit) egress label
control as defined in [EGRESS].
This subobject has the following format:
Component Interface Identifier ERO subobject
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
D.Papadimitriou (Editor) 5
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IPv4, IPv6 or unnumbered Component Interface Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: 1 bit
This bit must be set to 0.
Type:
10 (TBD) Component Interface identifier IPv4
11 (TBD) Component Interface identifier IPv6
12 (TBD) Component Interface identifier Unnumbered
Length:
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is
8 bytes for the Component Interface identifier types: IPv4
and Component Interface identifier Unnumbered. For
Component Interface identifier IPv6 type of sub-object, the
length field is 20 bytes.
U: 1 bit
This bit indicates the direction of the component
interface. It is 0 for the downstream interface. It is set
to 1 for the upstream interface and is only used for bi-
directional LSPs.
5.1 Processing of Component Interface Identifier ERO Subobject
The Component Interface Identifier ERO subobject identifies the
component of a bundled TE Link. This subobject MUST follow a
subobject containing the IP address, or the link identifier
[RFC3477], associated with the TE link on which it is to be used. It
is used to.
The following SHOULD result in "Bad EXPLICIT_ROUTE object" error
being sent upstream by a node processing an ERO that contains the
Component Interface ID sub-object:
o) The first component interface identifier subobject is not
preceded by a sub-object containing an IPv4 or IPv6 address,
or an interface identifier [RFC3477], associated with a TE
link.
o) The Component Interface Identifier ERO subobject follows a
subobject that has the L-bit set.
o) On unidirectional LSP setup, there is a Component Interface
Identifier ERO subobject with the U-bit set.
D.Papadimitriou (Editor) 6
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
o) Two Component Interface Identifier ERO subobjects with the
same U-bit values exist.
If a node implements the component interface identifier subobject,
it must check if it represents a component interface in the bundled
TE Link specified in the preceding subobject that contains the IP
address or interface identifier of the TE Link. If the content of
the component interface identifier subobject does not match a
component interface in the TE link, a "Bad EXPLICIT_ROUTE object"
error SHOULD be reported as "Routing Problem" (error code 24).
If the U-bit of the subobject being examined is cleared (0) and the
upstream interface specified in this subobject is acceptable, then
the value of the upstream component interface is copied in the TLV
of the IF_ID HOP object [RFC 3471]. In this case, the local decision
normally used to select the upstream component link is bypassed. If
this interface is not acceptable, a "Bad EXPLICIT_ROUTE object"
error SHOULD be reported as "Routing Problem" (error code 24).
If the U-bit of the subobject being examined is set (1), then the
value represents the component interface to be used for upstream
traffic associated with the bidirectional LSP. Again, if this
interface is not acceptable or if the request is not one for a
bidirectional LSP, then a "Bad EXPLICIT_ROUTE object" error SHOULD
be reported as "Routing Problem" (error code 24). Otherwise, the
component interface IP address/ identifier is copied into a TLV sub-
object as part of the IF_ID RSVP_HOP object.
The IF_ID RSVP_HOP object constructed as above MUST be included in
the corresponding outgoing Path message.
Note that, associated with a TE Link sub-object in the ERO, either
the upstream component interface or the downstream component
interface or both may be specified. As specified in [BUNDLE] there
is no relationship between the TE Link type (numbered or unnumbered)
and the Link type of any one of its components.
The component interface identifier ERO subobject is OPTIONAL.
Furthermore, component interface identifier ERO subobject and Label
ERO subobject (see [RFC 3471] and [RFC 3473]) may be included in the
ERO independently of each other. One of the following alternatives
applies:
o) When both sub-objects are absent, a node may select any
appropriate component link within the TE link and any label on
the selected component link.
o) When the Label subobject is only present for a bundled link, then
the selection of the component link within the bundle is a local
decision and the node may select any appropriate component link,
which can assume the label specified in the Label ERO.
o) When only the component interface identifier ERO subobject is
present, a node MUST select the component interface specified in
the ERO and may select any appropriate label value at the
specified component link.
o) When both component interface identifier ERO subobject and Label
D.Papadimitriou (Editor) 7
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
ERO subobject are present, the node MUST select the specified
component link and the specified label value on that component
link. When present, both subobjects may appear in any relative
order to each other but they MUST appear after the TE Link sub-
object that they refer to.
After processing, the component interface identifier subobjects are
removed from the ERO.
Inferred from above, the interface subobject should never be the
first subobject in a newly received message.
If the component
interface subobject is the first subobject in a received ERO, then
it SHOULD be treated as a "Bad strict node" error.
Note: Information to construct the Component Interface ERO subobject
may come from the same mean used to populate the label ERO
subobject. Procedures by which an LSR at the head-end of an LSP
obtains the information needed to construct the Component Interface
subobject are outside the scope of this document.
6. Signaling Component TE Links in (IF_ID)_RSVP_HOP object
This memo does not modify procedures for use of TLVs in the IF_ID
RSVP_HOP object, defined in [RFC3471], [RFC3473] and [RFC3477]. The
new TLVs can be used in the IF_ID RSVP_HOP object. The component ID
values in TLV types 6 and 7 are values local to the upstream node.
TLV type 6 is used with semantics similar to TLV type 4. TLV type 7
is used with semantics similar to TLV type 5.
When a component link part of a bundled TE Link fails and the LSP
traffic is "automatically" moved to another component link. This
must be followed not only by an IGP update on available resources
for the bundle but also by a soft state resync at the two ends of
the bundle (new states are on different interfaces, ideally without
doing any "local" make-before-break i.e. no PathErr message
exchange). Need to clearly differentiate this from span protection
where a single link or component link includes physical protection.
In the former case, the upstream node would change the IF_ID
information for the LSP on the new Path it sends and the downstream
node would update forwarding and protocol state. There would be no
impact further up or downstream (unless component link recording was
enabled in the RRO).
7. Reporting Component TE Links in RROs
A new OPTIONAL subobject of the Record Route Object (RRO) is used to
record component interface identifier of a (bundled) TE Link. This
subobject has the following format:
Component Interface Identifier RRO subobject
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.Papadimitriou (Editor) 8
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
|L| Type | Length |U| Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IPv4, IPv6 or unnumbered Component Interface Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: 1 bit
This bit must be set to 0.
Type:
10 (TBD) Component Interface identifier IPv4
11 (TBD) Component Interface identifier IPv6
12 (TBD) Component Interface identifier Unnumbered
Length:
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is
8 bytes for the Component Interface identifier IPv4 and
Component Interface identifier Unnumbered types. For
Component Interface identifier IPv6 type of sub-object, the
length field is 20 bytes.
U: 1 bit
This bit indicates the direction of the component
interface. It is 0 for the downstream interface. It is set
to 1 for the upstream interface and is only used for bi-
directional LSPs.
7.1 Processing of Component Interface identifier RRO Subobject
If a node desires component link recording, the "Component Link
Recording desired" flag (value TBD) should be set in the
LSP_ATTRIBUTES object, object that is defined in [RSVP-TE-
ATTRIBUTE]. Another alternate is to use an available flag in the
SESSION_ATTRIBUTE object [RFC3209]. The later makes the component
link recording request similar to the label recording request. These
alternatives need to be discussed with the CCAMP working group and
close accordingly.
Setting of "Component Link Recording desired" flag is independent of
the Label Recording flag in SESSION_ATTRIBUTE object as specified in
[RFC3209]. Nevertheless, the following combinations are valid:
1) If both Label and Component Link flags are clear, then neither
Labels nor Component Links are recorded.
2) If Label Recording flag is set and Component Link flag is clear,
then only Label Recording is performed as defined in [RFC3209].
3) If Label Recording flag is clear and Component Link flag is set,
then Component Link Recording is performed as defined in this
proposal.
D.Papadimitriou (Editor) 9
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
4) If both Label Recording and Component Link flags are set, then
Label Recording is performed as defined in [RFC3209] and also
Component Link recording is performed as defined in this
proposal.
In most cases a node initiates recording for a given LSP by adding
the RRO to the Path message. If the node desires Component Link
recording and if the outgoing TE link is bundled, then the initial
RRO contains the Component Link identifier (numbered or unnumbered)
as selected by the sender. As well, the "Component Link Recording
desired" flag is set in the LSP_ATTRIBUTE object. If the node also
desires label recording, it sets the Label_Recording flag in the
SESSION_ATTRIBUTE object.
When a Path message with the "Component Link Recording desired" flag
set is received by an intermediate node, if a new Path message is to
be sent for a downstream bundled TE link, the node adds a new
Component Link subobject to the RRO and appends the resulting RRO to
the Path message before transmission.
Note that, unlike Labels, Component Link identifiers are always
known on receipt of the Path message.
When the destination node of an RSVP session receives a Path message
with an RRO and the "Component Link Recording desired" flag set,
this indicates that the sender node needs TE route as well as
component link recording. The destination node initiates the RRO
process by adding an RRO to Resv messages. The processing mirrors
that of the Path messages
The Component Interface Record subobject is pushed onto the
RECORD_ROUTE object prior to pushing on the node's IP address. A
node MUST NOT push on a Component Interface Record subobject without
also pushing on the IP address or unnumbered Interface Id subobject
that identifies the TE Link.
When component interfaces are recorded for bi-directional LSPs,
component interface RRO subobjects for both downstream and upstream
interfaces MUST be included.
8. Backward Compatibility Issues
TBD.
9. Security Considerations
This draft introduces no new security considerations to either
[RFC3473] or [RFC3477]. GMPLS security is described in section 11
of [RFC3471] and refers to [RFC3209] for RSVP-TE.
10. IANA Considerations
IF_ID TLV type values are not currently tracked or managed by IANA.
This might be a good opportunity to move them under IANA control.
D.Papadimitriou (Editor) 10
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
This document defines the following:
1. Subobjects of the EXPLICIT_ROUTE object (C-Type 1):
- Component Interface identifier IPv4 10 (TBA)
- Component Interface identifier IPv6 11 (TBA)
- Component Interface identifier Unnumbered 12 (TBA)
2. Subobjects of the RECORD_ROUTE object (C-Type 1):
- Component Interface identifier IPv4 10 (TBA)
- Component Interface identifier IPv6 11 (TBA)
- Component Interface identifier Unnumbered 12 (TBA)
3. LSP Attributes Flag Registry value (if not included in the
SESSION_ATTRIBUT object flags)
- Component Link Recording desired 7 (TBA)
11. Intellectual Property Consideration
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.
12.1 IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
13. Acknowledgments
This document is the work of numerous authors and consists of a
composition of a number of previous documents in this area,
including:
D.Papadimitriou (Editor) 11
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
draft-farrel-ccamp-ifid-unnum-00.txt
draft-zamfir-explicit-resource-control-bundle-03.txt
14. References
14.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., et al., "Resource ReSerVation Protocol
(RSVP) -- Version 1 Functional Specification," RFC
2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997.
[RFC3209] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels," RFC 3209, December 2001.
[RFC3471] Berger, L. (Editor) et al., "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling -
Functional Description," RFC 3471, January 2003.
[RFC3473] Berger, L. (Editor) et al., "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions," RFC 3473, January 2003.
[RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered
Links in RSVP-TE", RFC 3477, January 2003.
[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.
14.2 Informative References
[CRANKBACK] Farrel, A. (Editor), "Crankback Signaling Extensions
for MPLS Signaling", Internet Draft (work in progress),
draft-ietf-ccamp-crankback-01.txt, January 2004.
[GMPLS-ARCH]Mannie, E. (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture," Internet Draft
(work in progress), draft-ietf-ccamp-gmpls-
architecture-07.txt, May 2003.
[GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in
Support of Generalized MPLS," Internet Draft (work in
progress), draft-ietf-ccamp-gmpls-routing-09.txt,
October 2003.
D.Papadimitriou (Editor) 12
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
[IF-ID] Farrel, A. et al., "Identification of Component Links
of Unnumbered Interfaces," Internet Draft (work in
progress), draft-farrel-ccamp-ifid-unnum-00.txt,
February 2004.
[ERC] Zamfir, A. et al., "Component Link Recording and
Resource Control for GMPLS Link Bundles," Internet
Draft (work in progress), draft-zamfir-explicit-
resource-control-bundle-03.txt, February 2004.
15. Authors Addresses
Zafar Ali
Cisco Systems Inc.
100 South Main St. #200
Ann Arbor, MI 48104, USA
Phone: (734) 276-2459
Email: zali@cisco.com
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Dimitri Papadimitriou (Editor)
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Arun Satyanarayana
Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615
McLean, VA 22102, USA
Phone: +1 703 847-1785
EMail: aruns@movaz.com
Anca Zamfir
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8, Canada
Phone: (613)-254-3484
EMail: ancaz@cisco.com
D.Papadimitriou (Editor) 13
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
D.Papadimitriou (Editor) 14