draft-ietf-mpls-rsvp-unnum-07.txt   draft-ietf-mpls-rsvp-unnum-08.txt 
Network Working Group Kireeti Kompella Network Working Group Kireeti Kompella
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: January 2003 Yakov Rekhter Expiration Date: April 2003 Yakov Rekhter
Juniper Networks Juniper Networks
Signalling Unnumbered Links in RSVP-TE Signalling Unnumbered Links in RSVP-TE
draft-ietf-mpls-rsvp-unnum-07.txt draft-ietf-mpls-rsvp-unnum-08.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 7 skipping to change at page 3, line 7
Consider an (unnumbered) link between LSRs A and B. LSR A chooses an Consider an (unnumbered) link between LSRs A and B. LSR A chooses an
identifier for that link. So is LSR B. From A's perspective we refer identifier for that link. So is LSR B. From A's perspective we refer
to the identifier that A assigned to the link as the "link local to the identifier that A assigned to the link as the "link local
identifier" (or just "local identifier"), and to the identifier that identifier" (or just "local identifier"), and to the identifier that
B assigned to the link as the "link remote identifier" (or just B assigned to the link as the "link remote identifier" (or just
"remote identifier"). Likewise, from B's perspective the identifier "remote identifier"). Likewise, from B's perspective the identifier
that B assigned to the link is the local identifier, and the that B assigned to the link is the local identifier, and the
identifier that A assigned to the link is the remote identifier. identifier that A assigned to the link is the remote identifier.
In the context of this document the term "Router ID" refers to the
"Router Address" as defined in [OSPF-TE], or "Traffic Engineering
Router ID" as defined in [ISIS-TE].
This section is equally applicable to the case of unnumbered This section is equally applicable to the case of unnumbered
component links (see [LINK-BUNDLE]). component links (see [LINK-BUNDLE]).
6. Unnumbered Forwarding Adjacencies 6. Unnumbered Forwarding Adjacencies
If an LSR that originates an LSP advertises this LSP as an unnumbered If an LSR that originates an LSP advertises this LSP as an unnumbered
Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR
uses the Forwarding Adjacency formed by this LSP as an unnumbered uses the Forwarding Adjacency formed by this LSP as an unnumbered
component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST
allocate an identifier to that Forwarding Adjacency (just like for allocate an identifier to that Forwarding Adjacency (just like for
skipping to change at page 3, line 48 skipping to change at page 4, line 11
link to the value that the LSR allocates to that Forwarding link to the value that the LSR allocates to that Forwarding
Adjacency, and the link remote identifier to the value carried in the Adjacency, and the link remote identifier to the value carried in the
Interface ID field of the Forward Interface ID object. Interface ID field of the Forward Interface ID object.
6.1. LSP_TUNNEL_INTERFACE_ID Object 6.1. LSP_TUNNEL_INTERFACE_ID Object
The LSP_TUNNEL_INTERFACE_ID object has a class number of type The LSP_TUNNEL_INTERFACE_ID object has a class number of type
11bbbbbb (to be assigned by IANA), C-Type of 1 and length of 12. The 11bbbbbb (to be assigned by IANA), C-Type of 1 and length of 12. The
format is given below. format is given below.
This object can optionally appear in either a Path message or a Resv
Figure 1: LSP_TUNNEL_INTERFACE_ID Object Figure 1: LSP_TUNNEL_INTERFACE_ID Object
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID | | LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface ID" message. In the former case, we call it the "Forward Interface ID"
for that LSP; in the latter case, we call it the "Reverse Interface for that LSP; in the latter case, we call it the "Reverse Interface
ID" for the LSP. ID" for the LSP.
7. Signalling Unnumbered Links in EROs 7. Signalling Unnumbered Links in EROs
A new subobject of the Explicit Route Object (ERO) is used to specify A new subobject of the Explicit Route Object (ERO) is used to specify
unnumbered links. This subobject has the following format: unnumbered links. This subobject has the following format:
Figure 2: Unnumbered Interface ID Subobject Figure 2: Unnumbered Interface ID Subobject
skipping to change at page 6, line 40 skipping to change at page 7, line 14
9. Security Considerations 9. Security Considerations
This document makes a small extention to RFC3209 [RSVP-TE] to refine This document makes a small extention to RFC3209 [RSVP-TE] to refine
and explicate the use of unnumbered links. As such it poses no new and explicate the use of unnumbered links. As such it poses no new
security concerns. In fact, one might argue that use of the extra security concerns. In fact, one might argue that use of the extra
interface identify could make an RSVP message harder to spoof. interface identify could make an RSVP message harder to spoof.
10. IANA Considerations 10. IANA Considerations
The responsible Internet authority (presently called the IANA) The IANA assigns values to RSVP protocol parameters. The current
assigns values to RSVP protocol parameters. The current document document defines a new subobject for the EXPLICIT_ROUTE object and
defines a new subobject for the EXPLICIT_ROUTE object and for the for the ROUTE_RECORD object. The rules for the assignment of
ROUTE_RECORD object. The rules for the assignment of subobject subobject numbers have been defined in [RSVP-TE], using the
numbers have been defined in [RSVP-TE], using the terminology of BCP terminology of BCP 26 "Guidelines for Writing an IANA Considerations
26 "Guidelines for Writing an IANA Considerations Section in RFCs". Section in RFCs". Those rules apply to the assignment of subobject
Those rules apply to the assignment of subobject numbers for the new numbers for the new subobject of the EXPLICIT_ROUTE and ROUTE_RECORD
subobject of the EXPLICIT_ROUTE and ROUTE_RECORD objects. objects.
Furthermore, the same Internet authority needs to assign a class Furthermore, the same Internet authority needs to assign a class
number to the LSP_TUNNEL_INTERFACE_ID object. This must be of the number to the LSP_TUNNEL_INTERFACE_ID object. This must be of the
form 11bbbbbb (i.e., this is an 8-bit number whose two most form 11bbbbbb (i.e., this is an 8-bit number whose two most
significant bits are 1). significant bits are 1).
11. Acknowledgments 11. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
12. Acknowledgments
Thanks to Lou Berger and Markus Jork for pointing out that the RRO Thanks to Lou Berger and Markus Jork for pointing out that the RRO
should be extended in like fashion to the ERO. Thanks also to Rahul should be extended in like fashion to the ERO. Thanks also to Rahul
Aggarwal and Alan Kullberg for their comments on the text. Finally, Aggarwal and Alan Kullberg for their comments on the text. Finally,
thanks to Bora Akyol, Vach Kompella, and George Swallow. thanks to Bora Akyol, Vach Kompella, and George Swallow.
12. References 13. References
12.1. Normative references 13.1. Normative references
[RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan, [RSVP-TE] 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
[GMPLS-RSVP] Ashwood, P., et al., "Generalized MPLS Signalling RSVP- [GMPLS-RSVP] Ashwood, P., et al., "Generalized MPLS Signalling RSVP-
TE Extensions", draft-ietf-mpls-generalized-rsvp-te-07.txt (work in TE Extensions", draft-ietf-mpls-generalized-rsvp-te-07.txt (work in
progress) progress)
[GMPLS-SIG] Ashwood, P., et al, "Generalized MPLS - Signaling [GMPLS-SIG] Ashwood, P., et al, "Generalized MPLS - Signaling
Functional Description", draft-ietf-mpls-generalized-signaling-08.txt Functional Description", draft-ietf-mpls-generalized-signaling-08.txt
(work in progress) (work in progress)
[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.
12.2. Non-normative references 13.2. Non-normative references
[LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering", draft-kompella-mpls- Bundling in MPLS Traffic Engineering", draft-kompella-mpls-
bundle-05.txt (work in progress) bundle-05.txt (work in progress)
[LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS
TE", draft-ietf-mpls-lsp-hierarchy-05.txt (work in progress) TE", draft-ietf-mpls-lsp-hierarchy-05.txt (work in progress)
[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-03.txt (work in progress)
[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-isis-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-07.txt (work in progress) gmpls-extensions-07.txt (work in progress)
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-07.txt
(work in progress)
13. Author Information [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-03.txt (work in progress)
14. 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
e-mail: kireeti@juniper.net e-mail: kireeti@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
 End of changes. 

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