Network Working Group L. Ong
Internet-Draft Ciena
Intended status: Informational R. Theillaud
Expires: April 21, 2010 Marben Products
October 18, 2009
Implementation Experience with OSPFv2 Extensions for ASON Routing
draft-ong-gmpls-ason-routing-exper-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 21, 2010.
Abstract
IETF CCAMP WG has defined a set of extensions to OSPFv2 to support
ASON routing requirements. These extensions have been given EXP
status rather than Standards Track and according to guidelines for
OSPFv2 have not been allocated standard codepoints by IANA.
This draft describes implementation and interoperability testing
experiences with ASON routing extensions to OSPFv2 which provide
equivalent routing functionality to the extensions defined in IETF
CCAMP with some differences in formatting of the extensions.
This summary of implementation and testing is provided to help move
Ong & Theillaud Expires April 21, 2010 [Page 1]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
ASON Routing extensions for OSPF to Standards Track.
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reachability . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Review of ASON Routing draft . . . . . . . . . . . . . . . 3
2.2. Tested IPv4 Reachability Advertisement . . . . . . . . . . 4
3. Link Attributes . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Review of ASON Routing draft . . . . . . . . . . . . . . . 4
3.2. Bandwidth Accounting for ITU-T SONET/SDH Layers . . . . . 4
3.2.1. SONET/SDH-specific connection availability . . . . . . 5
4. Routing Information Scope . . . . . . . . . . . . . . . . . . 7
4.1. Review of ASON Routing Draft . . . . . . . . . . . . . . . 7
4.2. Link Advertisement (Local and Remote TE Router ID
sub-TLVs) . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Reachability Advertisement (Local TE Router ID sub-TLV) . 8
4.4. New Reachable Address top-level TLV . . . . . . . . . . . 9
5. Routing Information Dissemination . . . . . . . . . . . . . . 10
6. Implementation and Testing Results . . . . . . . . . . . . . . 10
6.1. Standardization . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Ong & Theillaud Expires April 21, 2010 [Page 2]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
1. Introduction
This draft presents results of interoperability testing on the part
of the authors and others that have been involved in understanding
and prototyping routing for ASON as part of the OIF (Optical
Internetworking Forum). Some of the authors have contributed to the
work in IETF on ASON routing requirements and protocol evaluation.
Many of the requirements and protocol functions discussed in
[RFC4258] and [RFC4652] have been incorporated into prototyping work
at OIF. Experimental protocol extensions to OSPF were implemented to
support the functions identified in [RFC4258] and [RFC4652].
Note that these extensions have been tested in a transport-only
instance of OSPF, i.e. routing implementations supported only optical
routing and did not participate in any IP routing use of OSPF.
Since then, the IETF has published a draft ( [OSPF-ASON]) addressing
some of the features implemented by those prototypes. However, the
latest revision of [OSPF-ASON] (-09) no longer provides IETF-
standardized code points for such sub-TLVs, due to its Experimental
Status and the existing guidelines for allocation of codepoints for
OSPF.
This draft summarizes testing of ASON routing extensions done by the
authors and others participating in OIF interop testing to assist in
the process of moving ASON routing extensions to Standards Track.
2. Reachability
2.1. Review of ASON Routing draft
In order to advertise blocks of reachable address prefixes a
summarization mechanism was proposed in [OSPF-ASON].
This extension consists of a network mask (a 32-bit number indicating
the range of IP addresses residing on a single IP network/subnet).
The set of local addresses is carried in an OSPFv2 TE LSA node
attribute TLV (a specific sub-TLV is defined per address family,
i.e., IPv4 and IPv6, used as network-unique identifiers).
Similar functionality was implemented and tested by the authors and
others. At the time of initial prototyping, the OSPFv2 TE LSA node
attribute TLV had not been defined, so somewhat different formatting
was used to carry IP prefixes.
The tested solution used a new sub-TLV to carry the same information,
called the Reachable IPv4 Prefix sub-TLV. This sub-TLV was carried
Ong & Theillaud Expires April 21, 2010 [Page 3]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
in a new OSPFv2 Reachable Address TLV. Details of the TLV are given
in section 5.
2.2. Tested IPv4 Reachability Advertisement
The Reachable IPv4 Prefix sub-TLV used the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-type (EXP) | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Reachable Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addr length: specifies the length of the prefix as a number of Bits.
IPv4 Reachable Address: For example, the address prefix 192.10.3.0/24
can be advertised with an address of 193.10.3 and an addr_length =
24.
3. Link Attributes
3.1. Review of ASON Routing draft
[OSPF-ASON] defined additional terminology and scoping of link
attributes advertised in a GMPLS LSA. One attribute which was left
open for possible technology-specific enhancements was the the
Interface Switching Capability Descriptor (ISCD).
For prototyping purposes for control of SONET/SDH networks, the
following technology-specific enhancement was implemented.
3.2. Bandwidth Accounting for ITU-T SONET/SDH Layers
GMPLS Routing defines an Interface Switching Capability Descriptor
(ISCD) that delivers, among other things, information about the
(maximum/minimum) bandwidth per priority that an LSP can make use of.
Per [RFC4202] and [RFC4203], one or more ISCD sub-TLVs can be
associated with an interface. This information, combined with the
Unreserved Bandwidth (sub-TLV defined in [RFC3630], Section 2.5.8),
provides the basis for bandwidth accounting.
[OSPF-ASON] states that in the ASON context, additional information
may be included when representation and information in the other
Ong & Theillaud Expires April 21, 2010 [Page 4]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
advertised fields are not sufficient for a specific technology (e.g.,
SDH). The definition of technology-specific information elements was
left beyond the scope of [OSPF-ASON], in the draft.
3.2.1. SONET/SDH-specific connection availability
For SONET/SDH networks with switches capable of handling multiple
layer networks, a single link may be used for a number of TDM layers.
For example, an OC192 link may be used for STS-1, STS-3c, STS-12c,
STS-48c, STS-192c connections, switched by the same fabric.
GMPLS appears to offer a number of possible options for advertising
link characteristics where multiple layers are supported by the same
physical link.
One option is to advertise separate Link TLVs for each layer. A
second option is to advertise multiple ISCD sub-TLVs within a single
Link TLV for the link. A third option is to advertise a single Link
TLV and ISCD sub-TLV and attempt to derive bandwidth availability for
multiple TDM layers from this information.
All three options were found to have some disadvantages and instead a
technology-specific ISCD sub-TLV was defined containing information
that applies to multiple TDM layers.
This solution was implemented for the following reasons:
o If separate TLVs are advertised for each layer, then common
information such as LSA header information, link type, link ID,
link local and remote identifiers, protection type, administrative
group and shared risk are repeated for each layer.
o If separate ISCD sub-TLVs are advertised for each layer, then
common information such as the Switching Capability (TDM) and
Encoding Type (SONET/SDH) are repeated for each layer.
o Deriving bandwidth availability from a single ISCD sub-TLV which
contains the total available bandwidth and the minimum reservable
bandwidth yields potentially inaccurate results, since support of
standard concatenation requires sequential timeslots in a
particular position, and this can be blocked by a smaller signal
in that space. Some available bandwidth may not be usable as a
result.
A technology-specific ISCD sub-TLV that carried a compact description
of the number of unallocated timeslots at each supported SONET/SDH
signal type was used instead of separate Link TLVs or ISCD sub-TLVs
and carried exact availability information for each signal type. The
Ong & Theillaud Expires April 21, 2010 [Page 5]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
indication subfield was also removed as no longer necessary since
Arbitrary SONET/SDH is not supported.
The following technology-specific ISCD format was tested:
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 (EXP) | Length = 4 + n*4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Unallocated Timeslots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Unallocated Timeslots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// . . . //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Unallocated Timeslots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: n defines the number of signal types supported on this link,
and thus has a value greater than or equal to 1. Inherited from
[RFC4202], the Switching Capability field and the Encoding field MUST
take the following values for Sonet/SDH interfaces: Switching
Capability (8 bits): value 100 (TDM). Encoding (8 bits): value 5 for
Sonet/SDH. Reserved (16 bits): must be set to zero when sent and
ignored when received.
Signal Type (8 bits):
STS-1 SPE / VC-3 [RFC4606]
STS-3c SPE / VC-4 [RFC4606]
STS-12c SPE/VC-4-4c Exp
STS-48c SPE/VC-4-16c Exp
STS-192c SPE/VC-4-64c Exp
Number of Unallocated Timeslots (24 bits):
Specifies the number of identical unallocated timeslots per Signal
Type and per TE Link. As such, the initial value(s) of this TLV
indicates the total capacity in terms of number of timeslots per TE
Ong & Theillaud Expires April 21, 2010 [Page 6]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
link. The signal type included in the BW announcement is specific to
the layer link being reported and is not derived from some other
signal type (e.g. STS-48c is not announced as 16 x STS-3c).
For instance on an OC-192/STM-64 interface either the number of
STS-3c SPE/VC-4 unallocated timeslots is initially equal to 64, or
the number of STS-48c SPE/VC-4-16c unallocated timeslots is equal to
4 or even a combination of both type of signals depending on the
interface capabilities. Once one of these components gets allocated
for a given connection, the number of unallocated timeslots is
decreased by the number of timeslots this connection implies.
4. Routing Information Scope
4.1. Review of ASON Routing Draft
[OSPF-ASON] proposed extensions to allow the scope of routing
Information to allow flexibility between the relationship of The
advertising router and the TE router. Similar extensions with
slightly different format were implemented in testing.
4.2. Link Advertisement (Local and Remote TE Router ID sub-TLVs)
Implementations followed the concepts defined in [OSPF-ASON] to Allow
flexible relationship between the Router-ID and the TE Router-ID.
The following is given in [OSPF-ASON]:
A Router-ID (Ri) advertising on behalf multiple TE Router_IDs (Lis)
creates a 1:N relationship between the Router-ID and the TE
Router-ID. As the link local and link remote (unnumbered) ID
association is not unique per node (per Li unicity), the
advertisement needs to indicate the remote Lj value and rely on the
initial discovery process to retrieve the [Li;Lj] relationship. In
brief, as unnumbered links have their ID defined on per Li bases, the
remote Lj needs to be identified to scope the link remote ID to the
local Li. Therefore, the routing protocol MUST be able to
disambiguate the advertised TE links so that they can be associated
with the correct TE Router-ID.
The tested extensions used two sub-TLVs of the (OSPFv2 TE LSA) top
level Link TLV that define the local and the remote TE Router-ID.
These are combined into a single sub-TLV in [OSPF-ASON] (the Local
and Remote TE Router-ID sub-TLV), however implementation and testing
began before [OSPF-ASON] was defined.
The formats of the Local and Remote TE Router-ID sub-TLVs were:
Ong & Theillaud Expires April 21, 2010 [Page 7]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
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 (exp) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (exp) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Router-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These sub-TLVs were always included as part of the top level Link TLV
as it was assumed that the Router-ID could always advertise on behalf
of multiple TE Router-IDs.
4.3. Reachability Advertisement (Local TE Router ID sub-TLV)
When the Router-ID is advertised on behalf of multiple TE Router-IDs
(Lis), the routing protocol MUST be able to associate the advertised
reachability information with the correct TE Router-ID.
For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level Node
Attribute TLV was introduced in [OSPF-ASON]. Since this sub-TLV had
not yet been defined at the time of initial implementation, a sub-TLV
was defined independently for prototype testing. In this case the
format is the same.
The tested solution used a new sub-TLV of the (OSPFv2 TE LSA) top
level Reachable Address TLV (see section 5): the TE Router ID sub-
TLV.
The TE Router_ID sub-TLV used the following format:
Ong & Theillaud Expires April 21, 2010 [Page 8]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
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 (exp) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4. New Reachable Address top-level TLV
When the OSPFv2 extensions for ASON routing were designed for the
first OIF interoperability demonstrations,
draft-ietf-ospf-te-node-addr draft was at a very early stage, and the
Node Attribute top-level TLV was not available to carry reachable
prefixes. Instead a new experimental top-level TLV was defined: the
Reachable Address top-level TLV.
Contrary to [OSPF-ASON] where each Node Attribute top-level TLV
carries reachable prefixes for a single TE Router ID (so that if a
Router advertises reachable prefixes on behalf of multiple TE Router
IDs, it will originate multiple OSPFv2 TE LSAs with a Node Attribute
TLV), the Reachable Address top-level TLV may be used to advertise
reachable prefixes attached to multiple TE Router IDs: in order to do
so, a TE Router ID sub-TLV MUST appear before the Reachable Address
sub-TLV(s).
Ong & Theillaud Expires April 21, 2010 [Page 9]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
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 (exp) | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router_Id sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Address sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// . . . //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Address sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// . . . //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router_Id sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Address sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Address sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This tested format is functionally equivalent to the format defined
in [OSPF-ASON] but is independent of the function of advertising
local addresses of a router for MPLS TE LSPs as defined in
[OSPF-NODE].
5. Routing Information Dissemination
Subdivision of ASON Routing Areas as discussed in this section of
[OSPF-ASON] has not yet been implemented and tested.
6. Implementation and Testing Results
Testing of these protocol extensions was carried out at a number of
testing events from 2003-2009, most recently occurring over a period
of months during July-September 2007 and April-June 2009. There were
7 independent implementations tested at each event as listed below:
2007 interop test implementations:
Ong & Theillaud Expires April 21, 2010 [Page 10]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
o Alcatel-Lucent
o Ciena Corporation
o Ericsson
o Huawei Technologies
o Sycamore Networks
o Tellabs
o ZTE
2009 interop test implementations:
o Alcatel-Lucent
o Ciena Corporation
o Huawei Technologies
o Nokia Siemens Networks
o Sycamore Networks
o Tellabs
o ZTE
Initial implementation and interop testing of ASON routing extensions
began as early as 2003.
Further information about the testing conducted can be found at
http://www.oiforum.com/public/OIF_demos.html
All implementations utilized the ASON routing extensions described in
this draft.
Results were:
o prototype implementations were interoperable
o aligned TE database was achieved by participating implementations
o path computation was successfully achieved for connections
Ong & Theillaud Expires April 21, 2010 [Page 11]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
o connections were successfully set up at different SONET/SDH rates
using the TE database
6.1. Standardization
These testing results are provided in the interests of achieving
standard OSPFv2 protocol extensions to support ASON routing. The
extensions tested are very similar in functionality to the extensions
defined in [OSPF-ASON], with the exception of the technology-specific
ISCD sub-TLV used. The results of this implementation and testing
show that these functions are useful and implementable, and that ASON
routing extensions to OSPF should be Standards Track rather than
Experimental.
It is believed by the authors that the tested TLVs and sub-TLVs are
equivalent in functionality to the extensions defined in [OSPF-ASON]
and could be adopted by IETF as extensions to OSPF used in a
transport instance.
This would enhance the adoption of standard GMPLS routing extensions
for ASON as a set of implementations for these routing extensions
will have already been tested and these extensions would as a result
be available sooner for use in the industry.
7. IANA Considerations
Propose IANA allocate codepoints for new TLV/sub-TLVs for ASON
Routing.
8. Security Considerations
This document describes implementation and testing experience with
ASON routing extensions similar to those defined in [OSPF-ASON]. No
additional security issues are identified.
9. 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)
Ong & Theillaud Expires April 21, 2010 [Page 12]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
Thierry Marcot (France Telecom)
Evelyne Roch (Nortel Networks)
Jonathan Saddler (Tellabs)
Yoshiaki Sone (NTT Corporation)
Takehiro Tsuritani (KDDI R&D Laboratories)
10. References
10.1. Normative References
[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.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
10.2. Informative References
[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.
[OSPF-NODE]
Aggarwal, R., "Advertising a Router's Local Addresses in
OSPF TE Extensions, draft-ietf-ospf- te-node-addr, work in
progress", October 2009.
Ong & Theillaud Expires April 21, 2010 [Page 13]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
[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.
Authors' Addresses
Lyndon Ong
Ciena
P.O.Box 308
Cupertino CA 95015
USA
Phone: +1 408 962 4929
Email: lyong@ciena.com
Remi Theillaud
Marben Products
176 rue Jean Jaures
Puteaux 92800
France
Email: remi.theillaud@marben-products.com
Ong & Theillaud Expires April 21, 2010 [Page 14]
Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009
Copyright Notice
Copyright (c) 2009 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 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.
Ong & Theillaud Expires April 21, 2010 [Page 15]