draft-ietf-mpls-bundle-04.txt   draft-ietf-mpls-bundle-05.txt 
Internet Draft Kireeti Kompella
Network Working Group Kireeti Kompella Updates: 3471 Juniper Networks
Internet Draft Juniper Networks Category: Standards Track Yakov Rekhter
Expiration Date: January 2003 Yakov Rekhter Expiration Date: April 2005 Juniper Networks
Juniper Networks
Lou Berger Lou Berger
Movaz Networks Movaz Networks
October 2004
Link Bundling in MPLS Traffic Engineering Link Bundling in MPLS Traffic Engineering
draft-ietf-mpls-bundle-04.txt draft-ietf-mpls-bundle-05.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. 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
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
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
[RFC3471].
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
represents a way to group/map the information about certain physical represents a way to group/map the information about certain physical
resources (and their properties) that interconnect LSRs into the resources (and their properties) that interconnect LSRs into the
information that is used by Constrained SPF for the purpose of path information that is used by Constrained SPF for the purpose of path
computation, and by GMPLS signaling. computation, and by GMPLS signaling.
As further stated in [GMPLS-ROUTING], depending on the nature of As further stated in [GMPLS-ROUTING], depending on the nature of
resources that form a particular TE link, for the purpose of GMPLS resources that form a particular TE link, for the purpose of GMPLS
signaling in some cases a combination of <link identifier, label> is signaling in some cases a combination of <TE link identifier, label>
sufficient to unambiguously identify the appropriate resource used by is sufficient to unambiguously identify the appropriate resource used
an LSP. In other cases, a combination of <link identifier, label> is by an LSP. In other cases, a combination of <TE link identifier,
not sufficient. Such cases are handled by using the link bundling label> is not sufficient. Such cases are handled by using the link
construct which is described in this document. bundling construct which is described in this document.
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 <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". On "component links", and to the whole TE link as a "bundled link".
a bundled link a combination of <(bundled) link identifier, component Furthermore we restrict the identifiers that can be used to identify
link identifier, label> is sufficient to unambiguously identify the component links such that they have node scope. On a bundled link a
appropriate resources used by an LSP. combination of <component link identifier, label> is sufficient to
unambiguously identify the appropriate resources used by an LSP.
Since within each component link a label is sufficient to
unambiguously identify the resources used by an LSP, one could also
say that a component link is a TE link, and a bundled link is a
collection of TE links.
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
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
skipping to change at page 3, line 24 skipping to change at page 3, line 34
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
unique across both TE and component link identifiers.
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
Identifiers" of [RSVP-UNNUM]/[CRLDP-UNNUM]). Furthermore, link local Identifiers" of [RFC3477]/[RFC3480]). Furthermore, link local
identifiers for all unnumbered links of a given LSR (whether identifiers for all unnumbered links of a given LSR (whether
component links, Forwarding Adjacencies or bundled links) MUST be component links, Forwarding Adjacencies or bundled links) MUST be
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 be advertised Once a bundled link is determined to be alive, it can
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-
IS and OSPF, they should be accompanied by descriptions as to how 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 choose 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. If the ERO chooses the component link by means outside the scope not. The identification of a component link in an ERO is outside the
of this document, this section does not apply. Otherwise, the choice scope of this document. When the bundled link is identified in an
of the component link for the LSP is a local matter between the two ERO or is dynamically identified, the choice of the component link
LSRs at each end of the bundled link. for the LSP is a local matter between the two LSRs at each end of the
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
[GMPLS-SIG], the sender chooses a component link in each direction). [RFC3471], the sender chooses a component link in each direction).
For unidirectional LSPs, and the forward direction of bidirectional The handling of labels is not modified by this document.
LSPs, the sender of a Resv/MAPPING message chooses the label. For the
reverse direction of a bidirectional LSP, the sender of the
Path/REQUEST message selects the upstream label.
With RSVP the choice of the component link is indicated by the sender 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 of the Path message by including the IF_ID RSVP_HOP object in the
Path message, as described in section 8 of [GMPLS-RSVP]. With CR-LDP 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 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 REQUEST message by including the IF_ID TLV in the REQUEST message, as
described in section 8 of [GMPLS-CRLDP]. described in section 8 of [RFC3472].
If the component link is numbered, the IF_ID RSVP_HOP object, or With RSVP the choice of the component link is indicated by the sender
IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6 of the Path message by including the IF_ID RSVP_HOP object in the
address) TLVs (see [GMPLS-SIG]). The address carried in the TLV Path message, as described in section 8 of [RFC3473]. With CR-LDP
identifies the link for which label allocation must be done. 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].
If the component link is unnumbered, the IF_ID RSVP_HOP object, or [RFC3471] defines the Interface Identification TLV types. This
IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The value document specifies that the TLV types 1, 2 and 3 SHOULD be used to
carried in Type 3 TLV contains the identifier of the selected indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs.
component link assigned to the link by the sender of the Path/REQUEST Type 1 TLVs are used for IPv4 numbered component link identifiers.
message. Processing this object is the same as specified in Section Type 2 TLVs are used for IPv6 numbered component links identifier.
"Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV" of Type 3 TLVs are used for unnumbered component link identifiers. The
[RSVP-UNNUM]/[CRLDP-UNNUM]. Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used.
For the purpose of processing the IF_ID RSVP_HOP object or IF_ID TLV, Except in the special case noted below, for a unidirectional LSP,
an unnumbered component link formed by a Forwarding Adjacency is only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
treated the same way as an unnumbered TE link formed by a Forwarding TLV. This TLV indicates the component link identifier of the
Adjacency (see Section "Unnumbered Forwarding Adjacencies" of [RSVP- downstream data channel on which label allocation must be done.
UNNUM]/[CDLDP-UNNUM]).
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.
The first TLV always indicates the component link identifier of the
downstream data channel on which label allocation must be done. When
present, the second TLV always indicates the component link
identifier of the upstream data channel on which label allocation
must be done. When only one TLV is present, it indicates the
component link identifier for both downstream and upstream data
channels.
In the special case where the same label is to be valid across all
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
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
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
by setting the Interface ID field to the special value 0xFFFFFFFF.
Note that this special case applies to both unidirectional and
bidirectional LSPs.
Although 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.
4.3.1. Interface Identification TLV Format
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.
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
defined in [RFC3477]. Note this results in the renaming of the IP
Address field defined in [RFC3471].
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 [ISIS-TE] and [OSPF- parameters for component links was undertaken in [RFC3784] and
TE]; we use the terminology from [OSPF-TE]. [RFC3630]; we use the terminology from [RFC3630].
5.1. OSPF Link Type 5.1. OSPF Link Type
The Link Type of a bundled link is the (unique) Link Type of the The Link Type of a bundled link is the (unique) Link Type of the
component links. (Note: this parameter is not present in IS-IS.) component links. (Note: this parameter is not present in IS-IS.)
5.2. OSPF Link ID 5.2. OSPF Link ID
For point-to-point links, the Link ID of a bundled link is the For point-to-point links, the Link ID of a bundled link is the
(unique) Router ID of the neighbor. For multi-access links, this is (unique) Router ID of the neighbor. For multi-access links, this is
skipping to change at page 6, line 33 skipping to change at page 7, line 41
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 links. component link
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 [GMPLS-
ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p
is defined to be the maximum of the Maximum LSP Bandwidth at priority is defined to be the maximum of the Maximum LSP Bandwidth at priority
p of all of its component links. 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
skipping to change at page 7, line 38 skipping to change at page 9, line 10
zero, and the unreserved bandwidth and maximum LSP bandwidth of the zero, and the unreserved bandwidth and maximum LSP bandwidth of the
bundle must be recomputed. If all the component links associated with bundle must be recomputed. If all the component links associated with
a given bundled link are down, the bundled link MUST not be a given bundled link are down, the bundled link MUST not be
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 [RSVP-TE] or CR-LDP thus raises no new security issues for RSVP-TE [RFC3209] or CR-LDP
[CR-LDP]. [RFC3212].
8. References 8. References
8.1. Normative References 8.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-isis-gmpls- Extensions in Support of Generalized MPLS", draft-ietf-ibis-gmpls-
extensions-11.txt (work in progress) extensions-11.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-08.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-04.txt (work in progress)
[GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling [RFC3471] Berger, L., et al., "Generalized Multi-Protocol Label
Functional Description", draft-ietf-generalized-mpls- Switching (GMPLS) Signaling Functional Description", RFC 3471,
signalling-08.txt January 2003.
[GMPLS-RSVP] Ashwood, P., et al., "Generalized MPLS Signalling RSVP-
TE Extensions", draft-ietf-mpls-generalized-rsvp-te-07.txt
[GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-06.txt Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions.", RFC 3473, January 2003.
[ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic [RFC3472] Ashwood, P., Berger, L., et al., "Generalized Multi-
Engineering", draft-ietf-isis-traffic-02.txt (work in progress) Protocol Label Switching (GMPLS) Signaling Constraint-based Routed
Label Distribution Protocol (CR-LDP) Extensions.", RFC 3472,January
2003.
[OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to [RFC3784] Smit, H., Li, T., "Intermediate System to Intermediate
OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress) System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784,
June 2004.
[UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling [RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic Engineering
Unnumbered Links in CR-LDP", draft-ietf-mpls-crldp-unnum-01.txt (work (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
in progress)
[UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links [RFC3480] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling
in RSVP-TE", draft-ietf-mpls-rsvp-unnum-01.txt (work in progress) Unnumbered Links in CR-LDP", RFC 3480, February 2003. in progress)
[RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in
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.
[RSVP-TE] 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
[CR-LDP] 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 8.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-03.txt (work in progress) draft-ietf-ccamp-lmp-10.txt (work in progress)
9. Author Information 9. 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 301 468 9228 Voice: +1 703-847-1801
Email: lberger@movaz.com Email: lberger@movaz.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
11. Intellectual Property
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.
 End of changes. 

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