Network Working Group                                      L. Ong
Internet-Draft Ong, Ciena
Internet-Draft                                         A. Malis, Verizon
Intended status: Informational Standards Track           R. Theillaud
Expires: April 21, 2010 Theillaud, Marben Products
Expires: October 18, 2009

   Implementation Experience with 26, 2010
                                                       February 26, 2010

   OSPFv2 Extensions for ASON Routing
                 draft-ong-gmpls-ason-routing-exper-00 based on Implementation Experience
                 draft-ong-gmpls-ason-routing-exper-01

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, October 26, 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
   work has continued in [OSPFASON].

   This draft describes implementation and interoperability testing
   experiences with defines a set of proposed updates for a subset of the
   the ASON routing extensions to for OSPFv2 which provide
   equivalent routing functionality to the extensions defined in IETF
   CCAMP [OSPFASON].
   These proposed updates have already benefited from running code
   tested in multiple interoperability testing events, with some at least
   eight independent implementations. The differences in formatting of from [OSPFASON]
   are the extensions.

   This summary result of implementation field and interoperability testing is provided experience.

   These formats are proposed to help move either be folded in to [OSPFASON],
   or be a separate Standards Track RFC covering
   a subset of the ASON Routing extensions for OSPF to OSPFv2, as preferred by the
   working group. We believe that adopting these formats will help
   move those parts of [OSPFASON] towards Standards Track. Track, while
   preserving the functionality defined in [OSPFASON].

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  Comparison with [OSPFASON]. . . . . . . . . . . . . . . . . .  3
   3.  Reachability . . . . . . . .  3
     2.1.  Review of ASON Routing draft . . . . . . . . . . . . . . .  3
     2.2.  Tested IPv4 Reachability Advertisement . . . . . . .  4
     3.1.  ASON Routing Requirements  . . .  4
   3.  Link Attributes . . . . . . . . . . . . .  4
     3.2.  Local TE Router_ID sub-TLV . . . . . . . . . .  4
     3.1.  Review of ASON Routing draft . . . . . .  5
     3.3.  IPv4 Reachable Address Prefix sub-TLV  . . . . . . . . .  4
     3.2.  Bandwidth Accounting for ITU-T SONET/SDH Layers .  5
     3.4.  IPv6 Reachable Address Prefix sub-TLV  . . . .  4
       3.2.1.  SONET/SDH-specific connection availability . . . . . .  5
   4.  Routing Information Scope  . . . . . . . . . . . . . . . . . .  7  6
     4.1.  Review of  ASON Routing Draft Requirements  . . . . . . . . . . . . . . .  7 .  6
     4.2.  Link Advertisement (Local  Local and Remote TE Router ID
           sub-TLVs) Router_ID sub-TLVs . . . . . . . . . .  6
   5.  Link Attributes  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Reachability Advertisement (Local TE Router ID sub-TLV)
     5.1.  ASON Requirements  .  8
     4.4.  New Reachable Address top-level TLV . . . . . . . . . . .  9
   5.  Routing Information Dissemination . . . . . . . .  7
     5.2.  Link Component Availability Sub-TLV. . . . . . . 10 . . . . .  7
   6.  Implementation and Testing Results . . . . . . . . . . . . . . 10  9
     6.1.  Standardization  . . . . . . . . . . . . . . . . . . . . . 12  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12 10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 15 12

1.  Introduction

   This draft presents results of interoperability testing on

   The ITU-T defines the part architecture of the authors and others that have been involved Automatically Switched
   Optical Network (ASON) in understanding
   and prototyping [G.8080].

   [RFC4258] details the routing requirements for ASON as part of the OIF (Optical
   Internetworking Forum).  Some GMPLS suite of the authors have contributed
   routing protocols to support the
   work in IETF on ASON routing requirements capabilities and protocol evaluation.
   Many functionality of
   ASON control planes identified in [G.7715] and in [G.7715.1].

   [RFC4652] evaluates the IETF Link State Routing Protocols against the
   requirements and protocol functions discussed identified in
   [RFC4258] and [RFC4258]. Section 7.1 of [RFC4652] have been incorporated into prototyping work
   at OIF.  Experimental protocol extensions to OSPF were implemented
   summarizes the capabilities to be provided by OSPFv2 [RFC2328] in
   support of ASON routing. This document details a set of OSPFv2
   extensions supporting a subset of the functions capabilities identified in [RFC4258]
   [RFC4652] which have already been implemented and [RFC4652]. tested for
   interoperability across at least 8 independent implementations.

   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

   This draft ( [OSPF-ASON]) addressing
   some of also compares the features implemented by extensions to those prototypes.  However,
   defined in [OSPFASON], which defines experimental OSPFv2
   extensions in support of [RFC4652] capabilities. The changes from
   [OSPFASON] are the
   latest revision result of [OSPF-ASON] (-09) no longer provides IETF-
   standardized code points for such sub-TLVs, due to its Experimental
   Status field and interoperability testing
   experience, and are either minor format changes or supplementary
   information found useful in field testing.  We believe that adop-
   ting the existing guidelines for allocation of codepoints for
   OSPF. extensions in this draft will further progress [OSPFASON].

2.  Comparison with [OSPFASON]

   This draft summarizes testing defines formats similar to some defined in [OSPFASON].
   This section gives a high level comparison of ASON routing extensions done by the
   authors two formats.

2.1. Reachable Address Prefix Advertisement

   Uses a single TLV to carry multiple values of TE Router_ID and others participating
   associated IPv4 or IPv6 address prefixes, rather than separate
   TLVs as in OIF interop testing [OSPFASON].

   In the IPv4 prefix format, uses Prefix Length to assist indicate the
   prefix length rather than a Network Mask as in [OSPFASON] (Note
   [OSPFASON] uses Prefix Length for the process IPv6 prefix format).

2.2. Router Information Scoping

   Uses separate Sub-TLVs to carry Local and Remote TE Router_ID
   instead of moving ASON routing extensions a single Sub-TLV for both, as in [OSPFASON].

2.3. Link Attributes

   Advertises Link Component Availability at multiple TDM layers
   as opposed to Standards Track.

2.  Reachability

2.1.  Review or in addition to advertisement of ISCD for an
   individual TDM layer.

3.  Reachability

3.1.  ASON Routing draft

   In order Requirements

   [RFC4652] identifies the need for additional capabilities to
   advertise blocks of reachable address prefixes using a summarization
   mechanism was proposed in [OSPF-ASON].

   This extension consists of a network mask (a 32-bit number indicating either taking the range form of IP addresses residing on a single IP network/subnet).
   The set prefix length (which indicates
   the number of local addresses is carried significant bits in an OSPFv2 TE LSA node
   attribute the prefix) or a network mask.

   An OSPF Reachable Address Prefix 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
   to support this capability.   This TLV is advertised as the time payload
   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 Type 1 Traffic Engineering LSA [RFC3630]. It has 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              |          Length (variable)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Local TE_Router_Id sub-TLV to carry                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IPv4 or IPv6 Reachable Address sub-TLV             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                            . . .                            //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IPv4 or IPv6 Reachable Address sub-TLV             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                            . . .                            //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Local TE_Router_Id sub-TLV                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IPv4 or IPv6 Reachable Address sub-TLV             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                            . . .                            //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IPv4 or IPv6 Reachable Address sub-TLV             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   This format allows the same information,
   called Reachable Address Prefix TLV to advertise
   multiple TE Router_IDs associated with the advertising entity, as
   well as multiple Reachable Address Prefixes associated with these
   TE Router_IDs.

   Each IPv4 or IPv6 Reachable Address Prefix sub-TLV.  This sub-TLV was carried is associated
   specifically with the TE Router_ID preceding it in a new OSPFv2 Reachable Address the TLV.  Details of

3.2.  Local TE_Router_ID Sub-TLV

   The Local TE_Router_ID sub-TLV used the TLV are given
   in section 5.

2.2.  Tested IPv4 Reachability Advertisement 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 (tbd)        |           Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local TE Router_ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Local TE Router_ID field advertises a Local TE Router_IDentifier
   being advertised associated with the advertising entity.

3.3 IPv4 Reachable Address Prefix Sub-TLV

   The IPv4 Reachable Address Prefix sub-TLV used takes the following format: form:

    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)              Type (tbd)       |          Length (variable)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Addr length  Pref_length  |                Reserved                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  IPv4 Reachable Address Prefix                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Addr length: specifies the

   The following fields are defined:

   Pref_length:  length in bits of the Prefix

   IPv4 Reachable Address Prefix:  Each prefix is encoded as a number of Bits.

   IPv4
   32-bit word with trailing zero bit padding as necessary.

3.4 IPv6 Reachable Address: For example, Address Prefix Sub-TLV

   IPv6 prefixes were not implemented or tested.

4.  Routing Information Scope

4.1.  ASON Routing Requirements

   [RFC4652] identifies the address prefix 192.10.3.0/24
   can be advertised with need for an address of 193.10.3 extension to routing protocols
   to support non-1:1 relationships between the Router_ID and an addr_length =
   24.

3.  Link Attributes

3.1.  Review of ASON Routing draft

   [OSPF-ASON] defined additional terminology TE
   Router_ID, and scoping of link
   attributes advertised in as a GMPLS LSA.  One attribute which was left
   open result the need for possible technology-specific enhancements was the capability to advertise
   the
   Interface Switching Capability Descriptor (ISCD).

   For prototyping purposes for remote Lj value where Lj is a logical control plane entity that
   is associated to a single data plane (abstract) node.

4.2.  Local and Remote TE Router_ID Sub-TLVs

   In order to support this capability, two sub-TLVs of SONET/SDH networks, the
   following technology-specific enhancement was implemented.

3.2.  Bandwidth Accounting TE LSA Link
   TLV [RFC3630] are defined for ITU-T SONET/SDH Layers

   GMPLS Routing defines an Interface Switching Capability Descriptor
   (ISCD) that delivers, among other things, information about advertising the
   (maximum/minimum) bandwidth per priority that an LSP can make use of.
   Per [RFC4202] Local TE Router_ID
   and [RFC4203], one or more ISCD Remote TE Router_ID.  These use the following formats:

    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              |           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              |           Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Remote TE Router_ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   These sub-TLVs can be
   associated with an interface.  This information, combined with allow the
   Unreserved Bandwidth (sub-TLV defined in [RFC3630], Section 2.5.8),
   provides routing protocol to scope the basis advertised
   link attributes advertised in an OSPFv2 TE Link LSA for bandwidth accounting.

   [OSPF-ASON] states ASON
   routing.

5. Link Attributes

5.1 ASON Requirements

   [RFC4652] notes that in the ASON context, additional information
   may be included when representation and information in the other
   advertised fields bandwidth accounting
   representations 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 possible, taking the draft.

3.2.1.  SONET/SDH-specific connection availability

   For SONET/SDH networks with switches capable form of handling multiple
   layer networks, a single link may be used for a set of tuples
   <signal_type; number of TDM layers.
   For example, an OC192 link unallocated timeslots>, and that this
   representation may be used for STS-1, STS-3c, STS-12c,
   STS-48c, STS-192c connections, switched by the same fabric.

   GMPLS appears also require definition of additional signal
   types (from those defined in [RFC4606]) to offer a number represent support of possible options for advertising
   link characteristics where multiple layers are supported by
   contiguously concatenated signals,
   i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.

   It notes that 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 defined in [RFC4202] is to advertise a single Link
   TLV and ISCD sub-TLV and attempt to derive the most
   straightforward without requiring any bandwidth availability for
   multiple TDM layers accounting
   change from this information.

   All three options were found to have some disadvantages and instead a
   technology-specific an LSR perspective.  However, the 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
   in [RFC4202} must be advertised once per signal type
   (identified by the Minimum Reservable Bandwidth value) in
   order to provide an accurate advertisement of bandwidth
   for each layer, then signal.  For SONET/SDH links, it is common
      information such as LSA header information, link type, link ID,
      link local to support
   4-5 signal types (e.g., STS-1, 3c, 12c, 48c and remote identifiers, protection type, administrative
      group 192c) at once,
   and shared risk are repeated for each layer.

   o  If separate advertisement of 4-5 ISCD sub-TLVs are advertised for each layer, then
      common information such would consume about
   200 bytes as the Switching Capability (TDM) and
      Encoding Type (SONET/SDH) are repeated compared to 20-30 bytes for each layer.

   o  Deriving bandwidth availability from a single ISCD sub-TLV which
      contains the total available bandwidth and tuple format.

   Most of the minimum reservable
      bandwidth yields potentially inaccurate results, since support ISCD bytes are required to advertise 8 levels of
      standard concatenation requires sequential timeslots in a
      particular position, and
   priority.  We believe this overhead can be blocked by a smaller signal
      in that space.  Some available bandwidth may reduced as (a) ASON
   specifications do not be usable identify priority as a
      result.

   A technology-specific ISCD sub-TLV that carried a compact description
   of the number of unallocated timeslots an ASON service; and
   (b) TDM networks generally to not support preemption priority
   at each supported all, not to mention 8 levels.

5.2.  Link Component Availability Sub-TLV

   The Link Component Availability Sub-TLV carries an indication
   of SONET/SDH bandwidth at multiple link component signal type was used instead of separate Link TLVs or types as
   supplementary information to the ISCD sub-TLVs
   and carried exact sub-TLV.

   When multiple priorities are used, the Link Component Availability
   Sub-TLV can be interpreted as the availability information for each signal type.  The
   indication subfield was also removed as no longer necessary since
   Arbitrary SONET/SDH is not supported. Priority 7.

   The following technology-specific ISCD format was tested: is defined:

    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) (tbd)             |        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
   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 occupied
   either by the number of timeslots this being allocated for a 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 at the TE Router-ID.
   The following is given in [OSPF-ASON]:

   A Router-ID (Ri) advertising on behalf multiple TE Router_IDs (Lis)
   creates same or 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 larger
   signal type or by being blocked due 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 allocation 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].  Since this sub-TLV had
   not yet been defined at the time of initial implementation, a sub-TLV
   was defined independently timeslot 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 connection 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: smaller signal type, 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 number
   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] but unallocated timeslots is independent of decreased by the function of advertising
   local addresses of a router for MPLS TE LSPs as defined in
   [OSPF-NODE].

5.  Routing Information Dissemination

   Subdivision number of ASON Routing Areas as discussed in timeslots
   this section of
   [OSPF-ASON] has not yet been implemented and tested. connection implies.

6.  Implementation and Testing Results

   Initial implementation of ASON routing extensions began in 2003.
   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:

   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  Ericsson
   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
   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 this draft satisfy a subset of the technology-specific
   ISCD sub-TLV used.
   functionality identified in [RFC4258] and [RFC4652] for ASON
   routing.  The results of this implementation and interoperability testing
   show that these functions are useful and implementable, and that ASON
   routing extensions to OSPF should may be made Standards Track rather than
   Experimental.

   It is believed by the authors that
   Experimental, using the tested TLVs formats implemented and sub-TLVs are
   equivalent in functionality to the tested.

   Standardization of these 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 support
   would as a result
   be available sooner for use allow fast adoption in the industry. industry due to the presence of
   several existing implementations, i.e., running code.

7.  IANA Considerations

   Propose IANA allocate codepoints for new TLV/sub-TLVs for ASON
   Routing.
   Routing from the standard range.

8.  Security Considerations

   This document describes implementation and testing experience with
   ASON routing extensions similar to those defined in [OSPF-ASON]. [OSPFASON].  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 Sadler (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.
   [RFC2328]  Moy, J., "OSPF Version 2", RFC 2328,April 1998.
   [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 4202,February 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]

   [OSPFASON] 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. 2010.
   [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 4652,February 2006.

Authors' Addresses

   Lyndon Ong
   Ciena
   P.O.Box 308
   Cupertino  CA 95015
   USA

   Phone: +1 408 962 4929
   Email: lyong@ciena.com

   Andrew Malis
   Verizon
   117 West St.
   Waltham, MA 02451
   USA

   Email: andrew.g.malis@verizon.com
   Phone: +1 781 466 2362

   Remi Theillaud
   Marben Products
   176 rue Jean Jaures
   Puteaux  92800
   France

   Email: remi.theillaud@marben-products.com

Copyright Notice

   Copyright (c) 2009 2010 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 (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.