Implementation Experience with OSPFv2 Extensions for ASON Routing
draft-ong-gmpls-ason-routing-exper-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 22, 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 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Introduction
2.  Reachability
    2.1.  Review of ASON Routing draft
    2.2.  Tested IPv4 Reachability Advertisement
3.  Link Attributes
    3.1.  Review of ASON Routing draft
    3.2.  Bandwidth Accounting for ITU-T SONET/SDH Layers
        3.2.1.  SONET/SDH-specific connection availability
4.  Routing Information Scope
    4.1.  Review of ASON Routing Draft
    4.2.  Link Advertisement (Local and Remote TE Router ID sub-TLVs)
    4.3.  Reachability Advertisement (Local TE Router ID sub-TLV)
    4.4.  New Reachable Address top-level TLV
5.  Routing Information Dissemination
6.  Implementation and Testing Results
    6.1.  Standardization
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

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] (Brungard, D., “Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON),” November 2005.) and [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,” October 2006.) have been incorporated into prototyping work at OIF. Experimental protocol extensions to OSPF were implemented to support the functions identified in [RFC4258] (Brungard, D., “Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON),” November 2005.) and [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,” October 2006.).

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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.)) addressing some of the features implemented by those prototypes. However, the latest revision of [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.) (-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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.).

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 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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.) 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] (Kompella, K. and Y. Rekhter, “Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS),” October 2005.) and [RFC4203] (Kompella, K. and Y. Rekhter, “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS),” October 2005.), one or more ISCD sub-TLVs can be associated with an interface. This information, combined with the Unreserved Bandwidth (sub-TLV defined in [RFC3630] (Katz, D., Kompella, K., and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2,” September 2003.), Section 2.5.8), provides the basis for bandwidth accounting.

[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.) states that in the ASON context, additional information may be included when representation and information in the other 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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.), 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:

• 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.
• 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.
• 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 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] (Mannie, E. and D. Papadimitriou, “Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control,” August 2006.)

STS-3c SPE / VC-4 [RFC4606] (Mannie, E. and D. Papadimitriou, “Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control,” August 2006.)

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 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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.) 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:

 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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.). 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:

 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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.) 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).

    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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.) but is independent of the function of advertising local addresses of a router for MPLS TE LSPs as defined in [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.).

5.  Routing Information Dissemination

Subdivision of ASON Routing Areas as discussed in this section of [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.) 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:

• Alcatel-Lucent
• Ciena Corporation
• Ericsson
• Huawei Technologies
• Sycamore Networks
• Tellabs
• ZTE

2009 interop test implementations:

• Alcatel-Lucent
• Ciena Corporation
• Huawei Technologies
• Nokia Siemens Networks
• Sycamore Networks
• Tellabs
• 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:

• prototype implementations were interoperable
• aligned TE database was achieved by participating implementations
• path computation was successfully achieved for connections
• 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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.), 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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.) 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] (Papadimitriou, D., “OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress,” August 2009.). 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)

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

10.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2009).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.