draft-ietf-mpls-bundle-05.txt   draft-ietf-mpls-bundle-06.txt 
Internet Draft Kireeti Kompella Internet Draft Kireeti Kompella
Updates: 3471 Juniper Networks Updates: 3471, 3472, 3473 Juniper Networks
Category: Standards Track Yakov Rekhter Category: Standards Track Yakov Rekhter
Expiration Date: April 2005 Juniper Networks Expiration Date: June 2005 Juniper Networks
Lou Berger Lou Berger
Movaz Networks Movaz Networks
October 2004 December 2004
Link Bundling in MPLS Traffic Engineering Link Bundling in MPLS Traffic Engineering
draft-ietf-mpls-bundle-05.txt draft-ietf-mpls-bundle-06.txt
1. Status of this Memo 1. Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 13 skipping to change at page 1, line 47
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
2. Abstract 2. Abstract
For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
signaling in certain cases a combination of <link identifier, label> signaling in certain cases a combination of <link identifier, label>
is not sufficient to unambiguously identify the appropriate resource is not sufficient to unambiguously identify the appropriate resource
used by a Label Switched Path (LSP). Such cases are handled by using used by a Label Switched Path (LSP). Such cases are handled by using
the link bundling construct which is described in this document. the link bundling construct which is described in this document.
This document updates the interface identification TLVs defined in This document updates the interface identification TLVs defined in
[RFC3471]. GMPLS Signaling Functional Description, [RFC3471].
Contents
1 Status of this Memo ....................................... 1
2 Abstract .................................................. 1
3 Specification of Requirements ............................. 3
4 Link Bundling ............................................. 3
4.1 Restrictions on Bundling .................................. 4
4.2 Routing Considerations .................................... 4
4.3 Signaling Considerations .................................. 5
4.3.1 Interface Identification TLV Format ....................... 6
4.3.2 Errored Component Identification .......................... 6
5 Traffic Engineering Parameters for Bundled Links .......... 7
5.1 OSPF Link Type ............................................ 7
5.2 OSPF Link ID .............................................. 7
5.3 Local and Remote Interface IP Address ..................... 7
5.4 Local and Remote Identifiers .............................. 7
5.5 Traffic Engineering Metric ................................ 8
5.6 Maximum Bandwidth ......................................... 8
5.7 Maximum Reservable Bandwidth .............................. 8
5.8 Unreserved Bandwidth ...................................... 8
5.9 Resource Classes (Administrative Groups) .................. 8
5.10 Maximum LSP Bandwidth ..................................... 8
6 Bandwidth Accounting ...................................... 9
7 Security Considerations ................................... 9
8 IANA Considerations ....................................... 9
9 References ................................................ 10
9.1 Normative References ...................................... 10
9.2 Non-normative References .................................. 11
10 Author Information ........................................ 11
11 Full Copyright Statement .................................. 11
12 Intellectual Property ..................................... 12
3. Specification of Requirements 3. Specification of Requirements
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
4. Link Bundling 4. Link Bundling
As defined in [GMPLS-ROUTING], a TE link is a logical construct that As defined in [GMPLS-ROUTING], a TE link is a logical construct that
skipping to change at page 2, line 47 skipping to change at page 3, line 37
Consider a TE link such that for the purpose of GMPLS signaling a Consider a TE link such that for the purpose of GMPLS signaling a
combination of <TE link identifier, label> is not sufficient to combination of <TE link identifier, label> is not sufficient to
unambiguously identify the appropriate resources used by an LSP. In unambiguously identify the appropriate resources used by an LSP. In
this situation the link bundling construct assumes that the set of this situation the link bundling construct assumes that the set of
resources that form the TE link could be partitioned into disjoint resources that form the TE link could be partitioned into disjoint
subsets, such that (a) the partition is minimal, and (b) within each subsets, such that (a) the partition is minimal, and (b) within each
subset a label is sufficient to unambiguously identify the subset a label is sufficient to unambiguously identify the
appropriate resources used by an LSP. We refer to such subsets as appropriate resources used by an LSP. We refer to such subsets as
"component links", and to the whole TE link as a "bundled link". "component links", and to the whole TE link as a "bundled link".
Furthermore we restrict the identifiers that can be used to identify Furthermore we restrict the identifiers that can be used to identify
component links such that they have node scope. On a bundled link a component links such that they are unique for a given node. On a
combination of <component link identifier, label> is sufficient to bundled link a combination of <component link identifier, label> is
unambiguously identify the appropriate resources used by an LSP. sufficient to unambiguously identify the appropriate resources used
by an LSP.
The partition of resources that form a bundled link into component The partition of resources that form a bundled link into component
links has to be done consistently at both ends of the bundled link. links has to be done consistently at both ends of the bundled link.
Both ends of the bundled link also have to understand each others Both ends of the bundled link also have to understand each others
component link identifiers. component link identifiers.
The purpose of link bundling is to improve routing scalability by The purpose of link bundling is to improve routing scalability by
reducing the amount of information that has to be handled by OSPF reducing the amount of information that has to be handled by OSPF
and/or IS-IS. This reduction is accomplished by performing and/or IS-IS. This reduction is accomplished by performing
information aggregation/abstraction. As with any other information information aggregation/abstraction. As with any other information
aggregation/abstraction, this results in losing some of the aggregation/abstraction, this results in losing some of the
information. To limit the amount of losses one need to restrict the information. To limit the amount of losses one need to restrict the
type of the information that can be aggregated/abstracted. type of the information that can be aggregated/abstracted.
4.1. Restrictions on Bundling 4.1. Restrictions on Bundling
All component links in a bundle must begin and end on the same pair All component links in a bundle must begin and end on the same pair
of LSRs, have the same Link Type (i.e., point-to-point or multi- of LSRs, have the same Link Type (i.e., point-to-point or
access), the same Traffic Engineering metric, and the same set of multi-access), the same Traffic Engineering metric, and the same set
resource classes at each end of the links. of resource classes at each end of the links.
A Forwarding Adjacency may be a component link; in fact, a bundle can A Forwarding Adjacency may be a component link; in fact, a bundle can
consist of a mix of point-to-point links and FAs. consist of a mix of point-to-point links and FAs.
If the component links are all multi-access links, the set of IS-IS If the component links are all multi-access links, the set of IS-IS
or OSPF routers connected to each component link must be the same, or OSPF routers connected to each component link must be the same,
and the Designated Router for each component link must be the same. and the Designated Router for each component link must be the same.
If these conditions cannot be enforced, multi-access links must not If these conditions cannot be enforced, multi-access links must not
be bundled. be bundled.
Component link identifiers MUST have node wide scope and MUST be Component link identifiers MUST be unique across both TE and
unique across both TE and component link identifiers. component link identifiers on a particular node. This means that
unnumbered identifiers have node wide scope, and that numbered
identifiers have the same scope as IP addresses.
4.2. Routing Considerations 4.2. Routing Considerations
A component link may be either numbered or unnumbered. A bundled link A component link may be either numbered or unnumbered. A bundled link
may itself be numbered or unnumbered independent of whether the may itself be numbered or unnumbered independent of whether the
component links of that bundled link are numbered or not. component links of that bundled link are numbered or not.
Handling identifiers for unnumbered component links, including the Handling identifiers for unnumbered component links, including the
case where a link is formed by a Forwarding Adjacency, follows the case where a link is formed by a Forwarding Adjacency, follows the
same rules as for an unnumbered TE link (see Section "Link same rules as for an unnumbered TE link (see Section "Link
skipping to change at page 4, line 13 skipping to change at page 5, line 5
unique in the context of that LSR. unique in the context of that LSR.
The "liveness" of the bundled link is determined by the liveness of The "liveness" of the bundled link is determined by the liveness of
each of the component links within the bundled link - a bundled link each of the component links within the bundled link - a bundled link
is alive when at least one its component links is determined to be is alive when at least one its component links is determined to be
alive. The liveness of a component link can be determined by any of alive. The liveness of a component link can be determined by any of
several means: IS-IS or OSPF hellos over the component link, or RSVP several means: IS-IS or OSPF hellos over the component link, or RSVP
Hello, or LMP hellos (see [LMP]), or from layer 1 or layer 2 Hello, or LMP hellos (see [LMP]), or from layer 1 or layer 2
indications. indications.
Once a bundled link is determined to be alive, it can Once a bundled link is determined to be alive, it can be advertised
be advertised
as a TE link and the TE information can be flooded. If IS-IS/OSPF as a TE link and the TE information can be flooded. If IS-IS/OSPF
hellos are run over the component links, IS-IS/OSPF flooding can be hellos are run over the component links, IS-IS/OSPF flooding can be
restricted to just one of the component links. Procedures for doing restricted to just one of the component links. Procedures for doing
this are outside the scope of this document. this are outside the scope of this document.
In the future, as new Traffic Engineering parameters are added to IS- In the future, as new Traffic Engineering parameters are added to
IS and OSPF, they should be accompanied by descriptions as to how IS-IS and OSPF, they should be accompanied by descriptions as to how
they can be bundled, and possible restrictions on bundling. they can be bundled, and possible restrictions on bundling.
4.3. Signaling Considerations 4.3. Signaling Considerations
Typically, an LSP's ERO will identify the bundled link to be used for Typically, an LSP's ERO will identify the bundled link to be used for
the LSP, but not the component link, since information about the the LSP, but not the component link, since information about the
bundled link is flooded, but information about the component links is bundled link is flooded, but information about the component links is
not. The identification of a component link in an ERO is outside the not. The identification of a component link in an ERO is outside the
scope of this document. When the bundled link is identified in an scope of this document. When the bundled link is identified in an
ERO or is dynamically identified, the choice of the component link ERO or is dynamically identified, the choice of the component link
for the LSP is a local matter between the two LSRs at each end of the for the LSP is a local matter between the two LSRs at each end of the
bundled link. bundled link.
Signaling must identify both the component link to use and the label Signaling must identify both the component link to use and the label
to use. The choice of the component link to use is always made by the to use. The choice of the component link to use is always made by the
sender of the Path/REQUEST message (if an LSP is bidirectional sender of the Path/REQUEST message (if an LSP is bidirectional
[RFC3471], the sender chooses a component link in each direction). [RFC3471], the sender chooses a component link in each direction).
The handling of labels is not modified by this document. The handling of labels is not modified by this document.
With RSVP the choice of the component link is indicated by the sender Component link identifiers are carried in RSVP messages as described
of the Path message by including the IF_ID RSVP_HOP object in the in section 8 of [RFC3473]. Component link identifiers are carried in
Path message, as described in section 8 of [RFC3473]. With CR-LDP CR-LDP messages as described in section 8 of [RFC3473]. Additional
the choice of the component link is indicated by the sender of the processing related to unnumbered links is described in the
REQUEST message by including the IF_ID TLV in the REQUEST message, as "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV" and
described in section 8 of [RFC3472]. "Unnumbered Forwarding Adjacencies" sections of [RFC3477]/[RFC3480].
With RSVP the choice of the component link is indicated by the sender
of the Path message by including the IF_ID RSVP_HOP object in the
Path message, as described in section 8 of [RFC3473]. With CR-LDP
the choice of the component link is indicated by the sender of the
REQUEST message by including the IF_ID TLV in the REQUEST message, as
described in section 8 of [RFC3472]. Additional processing related
to unnumbered links is described in the "Processing the IF_ID
RSVP_HOP object"/"Processing the IF_ID TLV" and "Unnumbered
Forwarding Adjacencies" sections of [RFC3477]/[RFC3480].
[RFC3471] defines the Interface Identification TLV types. This [RFC3471] defines the Interface Identification TLV types. This
document specifies that the TLV types 1, 2 and 3 SHOULD be used to document specifies that the TLV types 1, 2 and 3 SHOULD be used to
indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs. indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs.
Type 1 TLVs are used for IPv4 numbered component link identifiers. Type 1 TLVs are used for IPv4 numbered component link identifiers.
Type 2 TLVs are used for IPv6 numbered component links identifier. Type 2 TLVs are used for IPv6 numbered component link identifiers.
Type 3 TLVs are used for unnumbered component link identifiers. The Type 3 TLVs are used for unnumbered component link identifiers. The
Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used. Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used.
Note, in Path and REQUEST messages, link identifiers MUST be
specified from the sender's perspective.
Except in the special case noted below, for a unidirectional LSP, Except in the special case noted below, for a unidirectional LSP,
only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
TLV. This TLV indicates the component link identifier of the TLV. This TLV indicates the component link identifier of the
downstream data channel on which label allocation must be done. downstream data channel on which label allocation must be done.
Except in the special case noted below, for a bidirectional LSP, only Except in the special case noted below, for a bidirectional LSP, only
one or two TLVs SHOULD used in an IF_ID RSVP_HOP object or IF_ID TLV. one or two TLVs SHOULD used in an IF_ID RSVP_HOP object or IF_ID TLV.
The first TLV always indicates the component link identifier of the The first TLV always indicates the component link identifier of the
downstream data channel on which label allocation must be done. When downstream data channel on which label allocation must be done. When
skipping to change at page 5, line 43 skipping to change at page 6, line 27
component links, two TLVs SHOULD used in an IF_ID RSVP_HOP object or component links, two TLVs SHOULD used in an IF_ID RSVP_HOP object or
IF_ID TLV. The first TLV indicates the TE link identifier of the IF_ID TLV. The first TLV indicates the TE link identifier of the
bundle on which label allocation must be done. The second TLV bundle on which label allocation must be done. The second TLV
indicates a bundle scope label. For TLV types 1 and 2 this is done indicates a bundle scope label. For TLV types 1 and 2 this is done
by using the special bit value of all ones (1), e.g., 0xFFFFFFFF for by using the special bit value of all ones (1), e.g., 0xFFFFFFFF for
a type 1 TLV. Per [RFC3471], for TLV types 3, 4 and 5, this is done a type 1 TLV. Per [RFC3471], for TLV types 3, 4 and 5, this is done
by setting the Interface ID field to the special value 0xFFFFFFFF. by setting the Interface ID field to the special value 0xFFFFFFFF.
Note that this special case applies to both unidirectional and Note that this special case applies to both unidirectional and
bidirectional LSPs. bidirectional LSPs.
Although SHOULD NOT be used, when used, the type 5 TLV MUST NOT be Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be
the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV. the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.
4.3.1. Interface Identification TLV Format 4.3.1. Interface Identification TLV Format
This section modifies section 9.1.1. of [RFC3471]. The definition of This section modifies section 9.1.1. of [RFC3471]. The definition of
the IP Address field of the TLV types 3, 4 and 5 is clarified. the IP Address field of the TLV types 3, 4 and 5 is clarified.
For types 3, 4 and 5 the Value field has the identical format as For types 3, 4 and 5 the Value field has the identical format as
the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object
defined in [RFC3477]. Note this results in the renaming of the IP defined in [RFC3477]. Note this results in the renaming of the IP
Address field defined in [RFC3471]. Address field defined in [RFC3471].
4.3.2. Errored Component Identification
When Interface Identification TLVs are used, the TLVs are also used
to indicate the specific components associated with an error. For
RSVP, this means that any received TLVs SHOULD be copied into the
IF_ID ERROR_SPEC object, see Section 8.2 in [RFC3473]. The Error
Node Address field of the object SHOULD indicate the TE Link
associated with the error. For CR-LDP, this means that any received
TLVs SHOULD be copied into the IF_ID Status TLV, see Section 8.2 in
[RFC3472]. The HOP Address field of the TLV SHOULD indicate the TE
Link associated with the error.
5. Traffic Engineering Parameters for Bundled Links 5. Traffic Engineering Parameters for Bundled Links
In this section, we define the Traffic Engineering parameters to be In this section, we define the Traffic Engineering parameters to be
advertised for a bundled link, based on the configuration of the advertised for a bundled link, based on the configuration of the
component links and of the bundled link. The definition of these component links and of the bundled link. The definition of these
parameters for component links was undertaken in [RFC3784] and parameters for component links was undertaken in [RFC3784] and
[RFC3630]; we use the terminology from [RFC3630]. [RFC3630]; we use the terminology from [RFC3630].
5.1. OSPF Link Type 5.1. OSPF Link Type
skipping to change at page 7, line 41 skipping to change at page 8, line 33
5.8. Unreserved Bandwidth 5.8. Unreserved Bandwidth
The unreserved bandwidth of a bundled link at priority p is the sum The unreserved bandwidth of a bundled link at priority p is the sum
of the unreserved bandwidths at priority p of all the component links of the unreserved bandwidths at priority p of all the component links
associated with the bundled link. associated with the bundled link.
5.9. Resource Classes (Administrative Groups) 5.9. Resource Classes (Administrative Groups)
The Resource Classes for a bundled link are the same as those of the The Resource Classes for a bundled link are the same as those of the
component link component links.
s.
5.10. Maximum LSP Bandwidth 5.10. Maximum LSP Bandwidth
The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth.
For an unbundled link the Maximum Bandwidth is defined in [GMPLS- For an unbundled link the Maximum Bandwidth is defined in
ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at
is defined to be the maximum of the Maximum LSP Bandwidth at priority priority p is defined to be the maximum of the Maximum LSP Bandwidth
p of all of its component links. at priority p of all of its component links.
The details of how Maximum LSP Bandwidth is carried in IS-IS is given The details of how Maximum LSP Bandwidth is carried in IS-IS is given
in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried
in OSPF is given in [GMPLS-OSPF]. in OSPF is given in [GMPLS-OSPF].
6. Bandwidth Accounting 6. Bandwidth Accounting
The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an
LSR with bundled links must apply admission control on a per- LSR with bundled links must apply admission control on a
component link basis. An LSP with a bandwidth requirement b and setup per-component link basis. An LSP with a bandwidth requirement b and
priority p fits in a bundled link if at least one component link has setup priority p fits in a bundled link if at least one component
maximum LSP bandwidth >= b at priority p. If there are several such link has maximum LSP bandwidth >= b at priority p. If there are
links, the choice of which link is used for the LSP is up to the several such links, the choice of which link is used for the LSP is
implementation. up to the implementation.
In order to know the maximum LSP bandwidth (per priority) of each In order to know the maximum LSP bandwidth (per priority) of each
component link, the Traffic Control module must track the unreserved component link, the Traffic Control module must track the unreserved
bandwidth (per priority) for each component link. bandwidth (per priority) for each component link.
A change in the unreserved bandwidth of a component link results in a A change in the unreserved bandwidth of a component link results in a
change in the unreserved bandwidth of the bundled link. It also change in the unreserved bandwidth of the bundled link. It also
potentially results in a change in the maximum LSP bandwidth of the potentially results in a change in the maximum LSP bandwidth of the
bundle; thus, the maximum LSP bandwidth should be recomputed. bundle; thus, the maximum LSP bandwidth should be recomputed.
skipping to change at page 9, line 13 skipping to change at page 9, line 41
advertised into OSPF/IS-IS. advertised into OSPF/IS-IS.
7. Security Considerations 7. Security Considerations
This document defines ways of utilizing procedures defined in other This document defines ways of utilizing procedures defined in other
documents referenced herein. Any security issues related to those documents referenced herein. Any security issues related to those
procedures are addressed in the referenced drafts. This document procedures are addressed in the referenced drafts. This document
thus raises no new security issues for RSVP-TE [RFC3209] or CR-LDP thus raises no new security issues for RSVP-TE [RFC3209] or CR-LDP
[RFC3212]. [RFC3212].
8. References 8. IANA Considerations
8.1. Normative References This document changes the recommended usage of two of the
Interface_ID Types defined in [RFC3471]. For this reason, the IANA
registry of GMPLS Signaling Parameters should be updated for those
types to read:
4 12 See below COMPONENT_IF_DOWNSTREAM - Deprecated [BUNDLE]
5 12 See below COMPONENT_IF_UPSTREAM - Deprecated [BUNDLE]
9. References
9.1. Normative References
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
Extensions in Support of Generalized MPLS", draft-ietf-ibis-gmpls- Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-
extensions-11.txt (work in progress) extensions-19.txt (work in progress)
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF
Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-
gmpls-extensions-12.txt (work in progress) gmpls-extensions-12.txt (work in progress)
[GMPLS-ROUTING] Kompella, K., Rekhter, Y., Banerjee, A. et al, [GMPLS-ROUTING] Kompella, K., Rekhter, Y., Banerjee, A. et al,
"Routing Extensions in Support of Generalized MPLS", draft-ietf- "Routing Extensions in Support of Generalized MPLS", draft-ietf-
ccamp-gmpls-routing-04.txt (work in progress) ccamp-gmpls-routing-09.txt (work in progress)
[RFC3471] Berger, L., et al., "Generalized Multi-Protocol Label [RFC3471] Berger, L., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471, Switching (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions.", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions.", RFC 3473, January 2003.
[RFC3472] Ashwood, P., Berger, L., et al., "Generalized Multi- [RFC3472] Ashwood, P., Berger, L., et al., "Generalized Multi-
skipping to change at page 9, line 50 skipping to change at page 10, line 42
2003. 2003.
[RFC3784] Smit, H., Li, T., "Intermediate System to Intermediate [RFC3784] Smit, H., Li, T., "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784,
June 2004. June 2004.
[RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic Engineering [RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003. (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3480] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling [RFC3480] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling
Unnumbered Links in CR-LDP", RFC 3480, February 2003. in progress) Unnumbered Links in CR-LDP", RFC 3480, February 2003.
[RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in
RSVP-TE", RFC 3477, January 2003. RSVP-TE", RFC 3477, January 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan,
V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001 RFC3209, December 2001
[RFC3212] Jamoussi, B., editor, "Constraint-Based LSP Setup using [RFC3212] Jamoussi, B., editor, "Constraint-Based LSP Setup using
LDP", RFC3212, December 2001 LDP", RFC3212, December 2001
8.2. Non-normative References 9.2. Non-normative References
[LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)",
draft-ietf-ccamp-lmp-10.txt (work in progress) draft-ietf-ccamp-lmp-10.txt (work in progress)
9. Author Information 10. Author Information
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: yakov@juniper.net Email: yakov@juniper.net
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
Voice: +1 703-847-1801 Voice: +1 703-847-1801
Email: lberger@movaz.com Email: lberger@movaz.com
10. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Intellectual Property 12. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at line 457 skipping to change at line 505
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Generated on: Mon Dec 20 11:40:16 2004
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/