Network Working Group E. Osborne
Internet-Draft Cisco Systems, Inc.
Intended status: Experimental P. Psenak
Expires: February 5, 2012 Cisco Systems.
August 4, 2011
Component and Composite Link Membership in OSPF
draft-ospf-cc-stlv-00
Abstract
This document provides a TLV and sub-TLV for OSPF to establish a
relationship between component and composite links in MPLS-TE opaque
LSAs.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 5, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Osborne & Psenak Expires February 5, 2012 [Page 1]
Internet-Draft ospf-cc August 2011
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Component TLV . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Removing link type and link ID sub-TLVs from C-TLV . . . . 3
2.2. Inheritance between Link TLV and C-TLV . . . . . . . . . . 3
2.3. Component/composite ID sub-TLV . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Osborne & Psenak Expires February 5, 2012 [Page 2]
Internet-Draft ospf-cc August 2011
1. Introduction
Composite links [I-D.ietf-rtgwg-cl-requirement] require the ability
to place MPLS-TE LSPs across specific components of a composite link.
One way to do this is to advertise both the composite and components
as links in the TE database using the mechanisms defined in
[RFC3630]. In order to do this, a relationship must be established
between a given composite link and its components. This document
provides a new top-level TLV to be advertised in the Traffic
Engineering LSA. This new TLV is necessary in order to ensure that
bandwidth reserved from a given component link is properly accounted
for at the component level, and to do so in a backward-compatible
manner. Along with this new top-level TLV, we define a sub-TLV to
identify the composite link to which a component belongs.
2. Component TLV
The component TLV (C-TLV) is very similar to the Link TLV [RFC3630].
The C-TLV defines a component link which belongs to a single
composite. A C-TLV MUST carry a CC-sTLV (see Section 2.3). A C-TLV
MUST NOT carry a Link Type or Link ID sub-TLV (see Section 2.1 for
the rationale). A C-TLV MUST otherwise follow all rules for sub-TLVs
that pertain to a Link TLV. In particular, all sub-TLVs which are
defined for use in a Link TLV are usable in the C-TLV.
2.1. Removing link type and link ID sub-TLVs from C-TLV
RFC3630 requires that a Link TLV carry both a Link Type and Link ID
sub-TLV. The Link Type describes the link as either p2p or
multiaccess. Composite and component links are p2p by definition,
and thus explicating this is unnecessary. For p2p links the Link ID
of the component is the Router ID of the neighbor at the other end;
as all components of a composite terminate on the same node, the Link
ID of the parent composite is inherited by the component link and
thus does not need to be specified.
2.2. Inheritance between Link TLV and C-TLV
A component may or may not carry all of the sub-TLVs that its parent
Link TLV does. For example, a component may share an administrative
group with its parent composite and thus can inherit the
administrative group from the parent, or might not have an IP
address. This section specifies inheritance rules used to determine
the value of various sub-TLVs inside the component link based on
their status in the parent composite:
Link type: per section 3.1, a C-TLV MUST NOT carry a Link Type sub-
Osborne & Psenak Expires February 5, 2012 [Page 3]
Internet-Draft ospf-cc August 2011
TLV.
Link ID: per section 3.1, a C-TLV MUST NOT carry a Link ID sub-TLV.
Local and remote interface IP addresses: if these are not specified
in the parent composite link then they MAY be omitted from the
component. Practically speaking it is not useful to advertise a link
without some sort of unique identifier, so it is expected that most
implementations will advertise a parent link with some sort of
identifier, either local/remote IP addresses or some other unique
identifier such as Link Local and Remote Identifiers [RFC4203]. If a
parent composite link carries a unique identifier a component link
SHOULD also carry a unique identifier. However, there is no
requirement that the types match; a composite MAY advertise a Link
Local/Remote Identifier while the component advertises local/remote
IP addresses, or vice versa. Deciding on the identifier used for a
component link is outside the scope of this document and is
implementation-specific.
Traffic engineering metric: if this is not included in the C-TLV, it
is inherited from the parent
Maximum bandwidth: if this is specified in the parent composite it
MUST be explicitly specified (that is, not inherited) in the
component link. If it is not specified in the parent it MAY be
specified in the component.
Maximum reservable bandwidth: if this is specified in the parent
composite it MUST be explicitly specified (that is, not inherited) in
the component link. If it is not specified in the parent it MAY be
specified in the component.
Unreserved bandwidth: if this is specified in the parent composite it
MUST be explicitly specified (that is, not inherited) in the
component link. If it is not specified in the parent it MAY be
specified in the component.
Administrative group: if this is not included in the C-TLV, it is
inherited from the parent.
Other sub-TLV types SHOULD follow a similar approach to the sub-TLVs
listed here. In general, the idea is that a component link should
advertise any properties which are unique to that component and
should inherit from the parent composite any properties which are
shared between the parent composite and the component.
Osborne & Psenak Expires February 5, 2012 [Page 4]
Internet-Draft ospf-cc August 2011
2.3. Component/composite ID sub-TLV
The association between a composite link and its components is made
using the component/composite ID sub-TLV (CC-ID sTLV). The CC-ID
sTLV is a sub-TLV carried in both the Link TLV of the OSPF Opaque TE
LSA and the C-TLV. It is a 32-bit field (4 octets) defined as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Composite ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Composite ID is a 32-bit value assigned to a composite on a given
system. The Composite ID MUST be unique to the advertising router.
The method of assignment of the Composite ID is out of the scope of
this document.
When carried in a Link TLV, the Composite ID identifies that link as
a composite link. When carried in a C-TLV, the Composite ID
identifies the composite link of which the given component is a
member. This association is necessary so that implementations which
are component-aware can decide whether to establish an LSP over a
composite or one of its components. All components of a given
composite MUST have an CC-ID sTLV, and the Composite ID of the
composite and all of its components MUST match. A link (component or
composite) MUST contain only one CC-ID sTLV. A node MAY advertise a
composite link with no components, but if a node advertises any
component links the node MUST also advertise an associated composite
link.
The CC-ID sTLV needs a number assigned to it by IANA. For now, the
sub-TLV number is TBD.
3. IANA Considerations
tbd
4. Security Considerations
There are no security considerations when using this sub-TLV; it is a
link property like any other, and provides no more and no less
exposure to security issues than the other sub-TLVs defined in
[RFC3630].
Osborne & Psenak Expires February 5, 2012 [Page 5]
Internet-Draft ospf-cc August 2011
5. Acknowledgements
Les Ginsberg, Padma Pilay-Esnault, Stefano Previdi, Tony Li, Abhay
Roy
6. Normative References
[I-D.ietf-rtgwg-cl-requirement]
Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
Yong, "Requirements for MPLS Over a Composite Link",
draft-ietf-rtgwg-cl-requirement-04 (work in progress),
March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
Authors' Addresses
Eric Osborne
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts 01719
Phone:
Fax:
Email: eosborne@cisco.com
URI:
Osborne & Psenak Expires February 5, 2012 [Page 6]
Internet-Draft ospf-cc August 2011
Peter Psenak
Cisco Systems.
Mlynske Nivy 43
Bratislava, 821 09
Slovakia
Phone:
Fax:
Email: eosborne@cisco.com
URI:
Osborne & Psenak Expires February 5, 2012 [Page 7]