[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CCAMP 56 agenda
At 09:55 PM 3/1/2003 -0800, Kireeti Kompella wrote:
Hi,
If you would like to speak at the CCAMP WG at the 56th IETF, please
reply to this email -- that will help the chairs track requests.
Also, please state which Internet draft(s) form the basis of the
talk that others may come prepared.
Dear Ron and Kireeti,
May we request a 5min slot for:
- " Explicit Resource Control over GMPLS Link Bundles",
draft-zamfir-explicit-resource-control-bundle-00.txt.
A copy of the draft is enclosed herewith. We have also requested posting
of the same copy to the Web, which should appear shortly. Abstract is
provided here for your quick reference.
Abstract
Explicit label/ resource control using the Label ERO and Label RRO
subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE
links are bundled, identification of label resource is not enough for the
purpose of explicit resource control. Specifically, when link bundling
[GMPLS-BUNDLE] is used, resource identification requires mechanisms to
specify the component link identifier, along the TE link identifier and
Label. This draft defines the extensions to RSVP [RFC2119, RFC3209] to
specify component link identifier for explicit resource control over
GMPLS link bundles.
Would you mind accepting this drafts within CCAMP?
Many thanks in advance.
Regards…. Anca and Zafar
Note: these are *not* presentations,
expositions, or tutorials.
A small number of slides that say what has changed *since the
last IETF*, issues that were raised in the interim, and resolutions
to those issues is the ideal. If there hasn't been a
discussion
on the mailing list, in many cases that is a sign that the topic
isn't (yet) ready for prime time.
Thanks,
Ron and Kireeti.
Networking Working Group
Internet Draft Anca Zamfir,
Zafar Ali
Document: draft-zamfir-explicit-resource- Cisco Systems, Inc.
control-bundle-00.txt
Expires: October 2002 March 2003
Explicit Resource Control over GMPLS Link Bundles
draft-zamfir-explicit-resource-control-bundle-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 working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Explicit label/ resource control using the Label ERO and Label RRO
subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE
links are bundled, identification of label resource is not enough for
the purpose of explicit resource control. Specifically, when link
bundling [GMPLS-BUNDLE] is used, resource identification requires
mechanisms to specify the component link identifier, along the TE
link identifier and Label. This draft defines the extensions to RSVP
[RFC2119, RFC3209] to specify component link identifier for explicit
resource control over GMPLS link bundles.
Conventions used in this document
Zamfir, A., Ali, Z. [Page 1]
draft-zamfir-explicit-resource-control-bundle-00.txt March 2003
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[RFC2119].
Sub-IP ID Summary
(This section to be removed before publication.)
SUMMARY
This document specifies extensions and mechanisms to RSVP-TE to
provide explicit resource control over GMPLS Link Bundles.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK?
This work fits in the MPLS box.
WHY IS IT TARGETED AT THIS WG?
This draft is targeted at this WG, because this it specifies
extensions to RSVP-TE signaling protocol for explicit resource
control over GMPLS Link Bundles [GMPLS-BUNDLE].
RELATED REFERENCES
Please refer to the Reference Section.
JUSTIFICATION
Please refer to the Abstract and Introduction Sections.
Table of Contents
1. Terminology....................................................3
2. Introduction...................................................3
3. Signaling Component Interface Identifier in ERO................4
3.1 Processing of Component Interface Identifier ERO Subobject.5
4. Component Interface Identifier RRO subobject...................6
4.1 Processing of Component Interface identifier RRO Subobject.7
5. Backward Compatibility Note....................................8
6. Security Considerations........................................8
7. Intellectual Property Considerations...........................8
References........................................................8
References........................................................8
Author's Addresses................................................9
Zamfir, A., Ali, Z. [Page 2]
draft-zamfir-explicit-resource-control-bundle-00.txt March 2003
1. Terminology
TE LINK - Unless specified otherwise, it refers to a bundled Traffic
Engineering link as defined in [GMPLS-BUNDLE]. Furthermore, the terms
TE Link and bundled TE Link are used interchangeably.
Component Interface - Refers to one of the components link in a TE
link.
Component Interface Identifier - Refers to an ID used to uniquely
identify a component link within a TE link.
2. Introduction
In classical MPLS that deals with unbundled packet switch capable
TE Links, one of the types of resources that an LSP originator can
control are the TE Link interfaces used by the LSP. This is done by
the use of an explicit route, i.e., ERO Object. Also, there are
applications where LSP initiator wishes to select resources on a
given TE Link [RFC 3471]. An example where such a mechanism is
desirable is when there are two LSPs to be "spliced" together, i.e.,
where the tail of the first LSP is to be "spliced" into the head of
the second LSP. Label ERO subobject is defined in [RFC 3473] for this
purpose. Similarly, for uni-directional LSPs the Label RRO subobject
is defined in [RFC3209] and is extended for bi-directional LSP in
[RFC 3471], [RFC 3473].
Link Bundling introduced by [GMPLS-BUNDLE], is used to improve
routing scalability by reducing the amount of TE related information
that needs to be flooded and handled by IGP in a TE network. This is
accomplished through aggregation and abstractization and in some
cases the complete resource identification is left as a local
decision. However, as described above there are cases when it is
desirable that a non-local (e.g., LSP Head) node does this.
When link bundling is used to aggregate multiple component links
into a TE link, label is not the only resource over TE link that
needs to be identified. In other words, the TE Link and the Label
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 a resource on a link, the triplet <TE Link, Component
Link, and Label> needs to be specified for the downstream direction
of a unidirectional LSP. In the case of bi-directional LSPs both
upstream and downstream triplets may be specified. In short, explicit
resource control over a bundled TE link also requires a way to
specify a component link within the TE link. References [RFC 3471],
[RFC 3473] and [GMPLS-BUNDLE] are deficient for this purpose.
This draft defines extensions to and describes the use of RSVP
[RFC2119, RFC3209] to specify component link identifier for explicit
resource control over GMPLS link bundles. Specifically, component
Zamfir, A., Ali, Z. [Page 3]
draft-zamfir-explicit-resource-control-bundle-00.txt March 2003
interface identifier ERO and RRO subobjects are defined to complement
their Label ERO and RRO counterparts. Procedures for processing
component interface identifier ERO and RRO subobjects and how they
can co-exist with the Label ERO and RRO subobjects are also
specified. If desired, it is possible to only include the component
interface subobjects in the ERO.
It has been also identified that the component interface
identifier ERO and RRO subobjects are also useful in Classic MPLS
networks with PSC TE links only.
3. Signaling Component Interface Identifier 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 has the following format:
Figure 1: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 Unnumbered
12 (TBD) Component Interface identifier IPv6
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
Zamfir, A., Ali, Z. [Page 4]
draft-zamfir-explicit-resource-control-bundle-00.txt March 2003
set to 1 for the upstream interface and is only used for
bi-directional LSPs.
3.1 Processing of Component Interface Identifier ERO Subobject
The Component Interface Identifier ERO subobject follows 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 identify the component of a bundled TE Link.
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 IP 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.
o Two Component Interface Identifier ERO subobjects with the same
U-bit values exist.
If a node supports 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 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] and 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 HOP.
The IF_ID HOP object constructed as above MUST be included in the
corresponding outgoing Path message.
Zamfir, A., Ali, Z. [Page 5]
draft-zamfir-explicit-resource-control-bundle-00.txt March 2003
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 [GMPLS-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.
Similarly, presence of the Label ERO sub-objects is not mandatory
[RFC 3471], [RFC 3473]. Furthermore, component interface identifier
ERO subobject and Label ERO subobject may be included in the ERO
independently of each other. 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. If only the Label subobject is
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. Similarly, 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. In the case where both
component interface identifier ERO subobject and Label ERO subobject
are present, the node MUST select the specified component link and
the specified label value on that component link. When both component
interface identifier ERO subobject and Label ERO subobject are
present, they 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.
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. However, such information
typically comes from the configuration data.
4. Component Interface Identifier RRO subobject
A new 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:
Zamfir, A., Ali, Z. [Page 6]
draft-zamfir-explicit-resource-control-bundle-00.txt March 2003
Figure 2: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Interface Identifier |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
L: 1 bit
This bit must be set to 0.
Type
10 (TBD) Component Interface identifier IPv4
11 (TBD) Component Interface identifier Unnumbered
12 (TBD) Component Interface identifier IPv6
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.
4.1 Processing of Component Interface identifier RRO Subobject
If a node desires component interface recording, then it sets the
Label Recording flag in SESSION_ATTRIBUTE object as specified in
[RFC3209]. In other words, when a node desires label recording, it
will also receive the component interface sub-objects in the RRO for
the bundled links from the nodes that implement this extension. When
the Label Recording flag in SESSION_ATTRIBUTE object is set and the
Zamfir, A., Ali, Z. [Page 7]
draft-zamfir-explicit-resource-control-bundle-00.txt March 2003
outgoing TE Link is a bundled link, nodes doing route recording
SHOULD include a Component Interface subobject along with the Label
subobject. 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.
5. Backward Compatibility Note
The extensions specified in this draft do not affect the
processing of the ERO, RRO at nodes that do not support them. A node
that receives an ERO that contains a Component Link ID subobject
SHOULD send ‘‘Bad EXPLICIT_ROUTE object" if it does not implement this
subobject. A node that does not support the Component Interface RRO
subobject but that does support Label subobject SHOULD only insert
the Label subobject in the RRO as per [RFC3471] and [RFC3473].
6. Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205]
remain relevant.
7. Intellectual Property Considerations
Cisco Systems may have intellectual property rights claimed in
regard to some of the specification contained in this document.
References
References
[RFC2205] " Resource ReSerVation Protocol (RSVP) - Version 1,
Functional Specification", RFC 2205, Braden, et al, September
1997.
[RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al,
RFC 3209, December 2001.
[GMPLS-BUNDLE] ‘‘Link Bundling in MPLS Traffic Engineering’’, draft-
ietf-mpls-bundle-04.txt, K. Kompella, et al, January 2003.
Zamfir, A., Ali, Z. [Page 8]
draft-zamfir-explicit-resource-control-bundle-00.txt March 2003
[RFC3471] Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, RFC 3471, L. Berger, et al,
January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-
TE) Extensions", RFC 3471, L. Berger, et al, January 2003.
[RFC3477] "Signaling Unnumbered Links in Resource ReSerVation
Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. Kompella,
Y. Rekhter, January 2003.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, S. Bradner, March 1997.
Author's Addresses
Anca Zamfir
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8
Canada.
Phone: (613)-254-3484
Email: ancaz@cisco.com
Zafar Ali
Cisco Systems Inc.
100 South Main St. #200
Ann Arbor, MI 48104
USA.
Phone: (734) 276-2459
Email: zali@cisco.com
Zamfir, A., Ali, Z.
[Page 9]