Network Working Group R. Theillaud
Internet-Draft Marben Products
Intended status: Informational L. Ong
Expires: April 29, 2010 Ciena
October 26, 2009
Additional functions for OSPFv2 extensions for ASON routing
draft-theillaud-gmpls-ason-routing-add-fcts-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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.
This Internet-Draft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Theillaud & Ong Expires April 29, 2010 [Page 1]
Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
[OSPF-ASON] defines OSPFv2 extensions to fulfill the requirements
defined in [RFC4258]. In OIF discussion of ASON routing, OIF members
have noted that some additional functionality beyond that defined in
[OSPF-ASON] would be useful for deployment of ASON routing by OIF
carriers.
The purpose of this document is to list such additional
functionalities, so that CCAMP experts study whether such
functionalities can be fulfilled by existing GMPLS mechanisms, or
whether extensions to [OSPF-ASON] are required.
Some proposals for potential extensions are provided for review by
IETF CCAMP.
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].
Theillaud & Ong Expires April 29, 2010 [Page 2]
Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Layer-scoped link attributes . . . . . . . . . . . . . . . . . 4
2.1. ITU-T G.7715.1 requirement . . . . . . . . . . . . . . . . 4
2.2. IETF extensions for ASON routing . . . . . . . . . . . . . 6
2.3. Proposed extension . . . . . . . . . . . . . . . . . . . . 6
3. Link associated local connection type . . . . . . . . . . . . . 7
3.1. IETF extensions for ASON routing . . . . . . . . . . . . . 7
3.2. Proposed extension . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Theillaud & Ong Expires April 29, 2010 [Page 3]
Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009
1. Introduction
The ITU-T Automatically Switched Optical Network (ASON) control plane
architecture is defined in [G.8080]. [G.7715] further defines the
architecture and requirements for routing in ASON networks; and
[G.7715.1] specifically refines such architecture and requirements
for link state protocols.
[RFC4258] captured those ITU-T requirements. [RFC4652] evaluated he
existing GMPLS routing protocols against the same requirements. The
necessary extensions to OSPFv2 to meet such requirements were defined
in [OSPF-ASON].
In discussing potential deployment of ASON routing, OIF members have
identified additional functions that would be useful for routing in
OIF carrier member ASON networks. The purpose of this document is to
identify and bring these functions to the IETF CCAMP working group,
so that the IETF experts may study how to fulfill such new functions
using existing GMPLS routing protocols mechanisms, or if necessary,
define extensions to [OSPF-ASON] to support these additional
functions.
The two additional functions discussed in this document are:
1. Layer-scoped link attributes
2. Link associated local connection type
This document also provides proposals for routing extensions that
have been discussed within OIF for ASON routing. They are provided
for the purposes of clarifying the function they address and serving
as proposals for extensions in CCAMP.
2. Layer-scoped link attributes
2.1. ITU-T G.7715.1 requirement
[G.7715.1] section 9.5.1 specifies the set of link characteristic
that are specific to a particular layer network.
o Link capacity: This attribute provides the sum of the available
and potential link connections for a particular network transport
layer.
o Link Weight: This attribute represents a vector of one or more
metrics, each of which indicates the relative desirability of a
particular link over another during path selection.
Theillaud & Ong Expires April 29, 2010 [Page 4]
Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009
o Resource Class: This attribute corresponds to a set of
administrative groups assigned by the operator to this link. A
link may belong to zero, one or more administrative groups.
o Local Connection Type: This attribute identifies whether the local
SNP represents a TCP, CP, or can be flexibly configured as either
a TCP or a CP.
o Link Availability: This attribute represents a vector of one or
more availability factors for the link or link end. Availability
may be represented in different ways between domains and within
domains. Within domains it may be used to represent a
survivability capability of the link or link end. In addition,
the availability factor may be used to represent a node
survivability characteristic.
o Diversity Support: This attribute represents diversity information
with respect to links, nodes and Shared Risk Groups (SRGs) that
may be used during path computation.
o Local Client Adaptations Supported: This attribute represents the
set of client layer adaptations supported by the TCP associated
with the Local SNPP. This is only applicable when the local SNP
represents a TCP or can be flexibly configured as either a TCP or
CP.
Protocol extensions for all of these attributes, except Local
Connection Type and Local Client Adaptations Supported, are already
defined for TE-Links in [RFC3630] and [RFC4203].
In OIF discussions it has been suggested that most of these
attributes would be common across ITU-T layer networks supported by a
particular link, however some attributes may take different values
for different layer networks.
For example, administrative weight associated with the link may have
one value for VC-3 connectivity across the link and another value for
VC-4 connectivity across the link in order to provide finer control
of routing on a per layer basis.
On the other hand diversity support is more likely to be based on
physical link characteristics such as conduits that may be traversed
by multiple physical links and be a common point of failure.
Given that some attributes may differ per layer network and others
are likely to be common across layer networks, an extension that
supports advertisement of common attributes on a per link basis but
allows some attributes to be scoped to a layer would be highly useful
Theillaud & Ong Expires April 29, 2010 [Page 5]
Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009
2.2. IETF extensions for ASON routing
[RFC4258] does not require to scope an attribute to a specific layer,
therefore [OSPF-ASON] does not provide a clear way to achieve such
scoping.
It has been recently suggested that GMPLS routing protocols may be
able to meet such a requirement by using a specific TE LSA per layer
(and so multiple TE LSAs for the same TE-Link). The LSA itself
scopes the attributes, the ISCD being used to identify the layer. If
multiple layers share the same attributes, then a single LSA with
multiple ISCDs is fine. However, this would lead to the
advertisement of multiple TE LSAs for the same TE-Link, and it is not
clear whether this is allowed by GMPLS routing protocols, or is an
efficient solution.
2.3. Proposed extension
[OIF-EXP] details how the link capacity attribute has been scoped to
a specific layer in ASON routing prototypes used in past OIF
interoperability demonstrations.
For all other attributes that must be scoped to a layer per
[G.7715.1], this draft proposes a new sub-TLV of the (OSPFv2 TE LSA)
top-level link TLV. The proposed Link Attribute Scoping sub-TLV is
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (tbd) | Length = 4 + x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Signal Type | Connect Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Scoped TE-Link Attribute SubTLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: x is the length of all the SubTLVs (including Type and Length
fields) contained within the scoping subTLV.
The Connect Type field is discussed in Section 3 below.
The following sub-TLVs can be encoded within a Link Attribute Scoping
sub-TLV:
o Traffic Engineering Metric sub-TLV.
Theillaud & Ong Expires April 29, 2010 [Page 6]
Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009
o Administrative Group sub-TLV (Resource Class).
A given sub-TLV may appear both as a sub-TLV of the top-level Link
TLV, and as a sub-TLV of a Link Attribute Scoping sub-TLV. In such a
case, the former is relevant for all layers except the layer
identified by the Link Attribute Scoping sub-TLV.
3. Link associated local connection type
The Local Connection Type is one of the link attribute required by
[G.7715.1].
This uni-directional attribute is used to identify if traffic
presented on the associated far-end interface has access to the
switching function contained within the network element for the
specific layer. If this attribute states that the far-end interface
does not have access to this switching function, path computation
will check to see if the element on the other side of the link is the
intended destination, and if not disregard the link.
3.1. IETF extensions for ASON routing
[OSPF-ASON] section 4.1 suggests the local connection type can be
inferred from ISCDs.
The ISCD provides three fields that can be used to identify a layer:
a switching type, an encoding type and for some switching types, a
minimun bandwidth. However, these three fields together may not
allow distinguishing every layer, and as a consequence relying on
ISCDs to infer each link-end local connection type may not work for
all layers.
One example that was brought up to the authors is about
distinguishing:
1. An interface that supports high-order VC-4 and high-order VC-3
layers.
2. An interface that supports high-order VC-4 and low-order VC-3
layers.
3.2. Proposed extension
The Connect Type field of the Link Attribute Scoping sub-TLV defined
in Section 2.3 can be used to specify the link connection type.
The local connection type link attribute is considered layer-
Theillaud & Ong Expires April 29, 2010 [Page 7]
Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009
specific. This proposed extension carries the local connection type
within the Link Attribute Scoping sub-TLV, and therefore scopes this
attribute to a specific layer.
The connection type is encoded using a bit vector:
o 0bxxxxxxx1 - Transit (i.e. CTP)
o 0bxxxxxx1x - Trail Sink (i.e. TTP)
Other bits are in this bit-vector are reserved, and must be sent as 0
and ignored on reception.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
This document does not identify any security issues.
6. Acknowledgements
The authors would like to thank the following OIF members for their
comments and support for this document:
Richard Graveman (Department of Defense)
Hans-Martin Foisel (Deutsche Telekom)
Thierry Marcot (France Telecom)
Evelyne Roch (Nortel Networks)
Jonathan Saddler (Tellabs)
Yoshiaki Sone (NTT Corporation)
Takehiro Tsuritani (KDDI R&D Laboratories)
Theillaud & Ong Expires April 29, 2010 [Page 8]
Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009
7. Normative References
[G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and requirements
for routing in the automatically switched optical
networks", June 2002.
[G.7715.1]
ITU-T Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture
and requirements for Link State Protocols", February 2004.
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON)", June 2006.
[OIF-EXP] Ong, L., "Implementation Experience with OSPFv2 Extensions
for ASON Routing,
draft-ong-gmpls-ason-routing-exper-00.txt, work in
progress", October 2009.
[OSPF-ASON]
Papadimitriou, D., "OSPFv2 Routing Protocols Extensions
for ASON Routing,
draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in
progress", August 2009.
[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.
[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol
Label Switching (GMPLS) Routing for the Automatically
Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4652] Papadimitriou, D., L.Ong, Sadler, J., Shew, S., and D.
Ward, "Evaluation of Existing Routing Protocols against
Automatic Switched Optical Network (ASON) Routing
Requirements", RFC 4652, October 2006.
Theillaud & Ong Expires April 29, 2010 [Page 9]
Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009
Authors' Addresses
Remi Theillaud
Marben Products
176 rue Jean Jaures
Puteaux 92800
France
Email: remi.theillaud@marben-products.com
Lyndon Ong
Ciena
P.O.Box 308
Cupertino CA 95015
USA
Phone: +1 408 962 4929
Email: lyong@ciena.com
Theillaud & Ong Expires April 29, 2010 [Page 10]