Internet Draft

Internet Engineering Task Group                              Jin Ho Hahm
Internet-Draft                                                      ETRI
                                                            Kwang-il Lee
Expiration Date: May 2001                                           NIST

                                                           November 2000


 Bandwidth Provisioning and Restoration Mechanisms in Optical Networks

                 draft-hahm-optical-restoration-00.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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/lid-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.


Abstract


   With the advent of tunable lasers and optical switches, dynamic
   configuration of optical networks has become possible.  This
   Internet-Draft presents a signaling mechanism for bandwidth
   provisioning and restoration based on this dynamic configuration of
   optical networks.  The mechanism adopted uses a 1:N restoration
   scheme, preparing the backup lightpath in advance before failures
   occur.


1. Introduction



Hahm et al                                                      [Page 1]


draft-hahm-optical-restoration-00.txt                      November 2000


   In general, Internet backbone networks are overbuilt in comparison to
   average traffic volumes, in order to support fluctuations in traffic
   levels. Therefore, constructed network facilities are in a sense
   wasted most of the time.

   One of the most important concepts in network management is
   maintaining the survivability of networks.  When there are link
   failures or the like, any affected routes should be replaced with
   functioning ones as soon as possible.  SONET can achieve this, with a
   guaranteed short recovery time of 50msec, but is wasteful because it
   requires 1:1 backup network resources.  If instead an adaptive 1:N
   restoration mechanism can be applied, network survivability can still
   be enhanced while minimizing the waste in network resources.

   This Internet Draft proposes a mechanism for bandwidth provisioning
   and restoration processes which meets this goal, and defines the
   associated signaling and message types.

2. Basic concept for bandwidth provisioning and restoration

   This section describes the basic concept of bandwidth provisioning
   and restoration mechanisms in optical networks.

o OXC system architecture

   The OXC system architecture for lambda switching has been introduced
   in several Internet-Drafts[1]. Our proposed bandwidth provisioning
   and restoration mechanisms are based on this architecture.

   The internal processing in OXC system for lambda switching is briefly
   outlined here.  This is presented only as an aid to understanding, as
   other basic mechanisms would also suffice.

   An Optical Crossconnect (OXC) has several incoming and outgoing
   lambda ports, connected to adjacent OXCs, and several incoming and
   outgoing  data ports attached to a controlling router. An OXC has an
   OXC Switching Controller (OSC) and OXC switch fabric.

   The OSC converts the received messages (mentioned in section 5) to
   the proper control command, and sends this command to the OXC fabric.
   The commands to control the OXC fabric are as follows: connect (and
   disconnect) between an incoming lambda port and outgoing lambda port;
   connect (and disconnect) between an incoming lambda port and outgoing
   data port; connect (and disconnect) between an incoming data port and
   an outgoing lambda port.

   Based on these commands, a chain of connections through OXCs can be
   formed, the lightpath.  The OXC starting a lightpath is called the
   ingress OXC, and the OXC ending a lightpath is called the egress OXC.
   The OXC inside the lightpath are called the intermediate OXC.

   An OXC fabric receives commands from the OSC, and replies whether the


Hahm et al                                                      [Page 2]
   

draft-hahm-optical-restoration-00.txt                      November 2000


   command was successful or not. The OSC then converts the result into 
   the form  of a message (described in section 5) to send to the
   counter OSC through the network.



           +---------+
           |         |  +-----------------------+
           |   IP    |  |                       |
           | Network |  |        Router         |
           |         |  |                       |
           +---------+  +--+--+--+-----+--+--+--+
                A          A  A  A     |  |  |
                |          |  |  |     |  |  |
                |          |  |  |     |  |  |
           +----|----------|--|--|-----|--|--|---------+
           |    V          |  |  |     |  |  |         |
           | +-----+       |  |  |     |  |  |         |
           | | OSC |<--+   |  |  |     |  |  |   OXC   |
           | +-----+   |   |  |  |     |  |  |         |
           |         +-V---|--|--|-----|--|--|-----+   |
           |         |     |  |  |     V  V  V     |   |
        outgoing data port O  O  O     O  O  O incoming data port
           |         |        |           |  |     |   |
   -->>-----------------O-----+           |  +--O--------------->>--
   -->>-----------------O-------------\   +-----O--------------->>--
   -->>-----------------O              \--------O--------------->>--
   -->>-----------------O-----------------------O--------------->>--
    incoming lambda  |  port    OXC Fabric    port | outgoing lambda
           |         +-----------------------------+   |
           |                                           |
           +-------------------------------------------+

                  (Fig.1) OXC system architecture

o Control channel between OXC switching controllers

   This Draft assumes that control channels between OSCs must be
   maintained to exchange signaling information. The details of the
   mechanisms required are outside the scope of the Draft.


o Gathering of link state information for lightpath computation

   The best route for lightpaths can be calculated based on link state
   information of optical resources, which varies dynamically in optical
   networks.  Many useful mechanisms for exchanging the link state
   information have been introduced by extending existing routing
   protocol such as OSPF or IS-IS LSA[2,3,4,5,6] in the optical network
   environment.  This Draft assumes these link state information
   exchange mechanisms.



Hahm et al                                                      [Page 3]


draft-hahm-optical-restoration-00.txt                      November 2000


   The minimum link state information required to decide lightpaths is
   as follows: unused lambdas in links, unused output data ports in
   ingress routers, and unused input data ports in egress routers.
   Because the route of a lightpath is decided at the ingress router,
   the status of output data ports of the ingress router can be obtained
   without explicit LSA exchange.  However, the status of input data
   ports of each router has to be distributed.

   Every ingress router has to know the SRLG (Shared Risk Link Group)
   value of every link to compute lightpaths which do not share the same
   risk of potential damages. These SRLG values do not change, and so
   this information is exchanged only once.

   In order to know whether to connect between incoming lambdas and
   outgoing lambdas of different wavelengths, the ingress router has to
   know the availability of lambda converters in all OXCs. Currently,
   this Draft simply assumes that all OXCs have enough lambda
   converters.


o Triggering of lightpath generation

   It is determined by network management functions what lightpaths are
   generated, from which ingress OXC, through which intermediate OXCs,
   to which egress OXC. Therefore, in this Draft we only consider the
   signaling procedure after determining the route of the lightpath.

   In general the establishment of an LSP in MPLS can be divided into
   two cases: pre-establishment before data traffic arrives at the
   ingress router, and post-establishment after data traffic arrives at
   the ingress router.  In the latter case, LSPs must be created quickly
   enough to handle the data traffic waiting at the ingress router for
   transmission.

   The creation of lightpath will not in general be so time-critical, as
   they will only be created in response to long-term changes in traffic
   volume.  Since the number of lightpaths being created per unit time
   is so much less than the number of LSPs in MPLS, the scalability of
   lightpath management is much higher than MPLS.

   The ingress OXC is in charge of the creation, deletion, and
   restoration of lightpaths.


o Detection of damaged lightpaths

   If some optical link is damaged physically, all the lightpaths
   passing through this link must be affected.  Generally in case of an
   all-optical network not using optical/electrical/optical(OEO)
   conversion, damage to a lightpath or drop of light signal level
   cannot be easily detected.  However because the egress OXC receives
   the light signal and converts it back to an electrical signal, any


Hahm et al                                                      [Page 4]
   

draft-hahm-optical-restoration-00.txt                      November 2000


   problems arising with the lightpath can be detected there. Therefore
   the responsibility for the detection of damaged lightpaths lies with 
   the egress OXC.


o Strict explicit routing vs. loose explicit routing

   In CR-LDP, both strict  explicit routing and loose explicit routing
   mechanisms may be used. However, in this scheme for lambda switching,
   only strict explicit routing is preferred to designate the lightpath.
   By using strictly explicit routing, optical network resources can be
   managed more precisely, and the rate of success for lightpath
   creation can be enhanced.


o Decision of backup lightpath

   In this Draft, we adopt the method of pre-establishment of backup
   lightpaths in advance of link failure.  This minimizes the
   restoration time, especially when the restoration process must be
   carried out simultaneously for a large number of damaged lightpaths
   sharing the same damaged link.

   In this Draft, we choose the 1:N restoration mechanism, where N
   primary lightpaths share one backup lightpath.  The size of N will
   depend on the topological characteristics of the network.  We say
   that the N primary lightpath and one backup lightpath  share the same
   restoration group.  The weakness of the 1:N restoration mechanism is
   that, after an initial failure and before reprovisioning, it cannot
   support restoration for subsequent failures to other lightpaths in
   the same restoration group.  This defect could be remedied at the
   expense of greater complexity through a 2 (or more):N restoration
   mechanism. Such a mechanism could be supported through the scheme
   described here, but will not be further considered at this time.

   To decide on the grouping of primary lightpaths and backup lightpath,
   the SRLG values of links are considered.  Because a lightpath travels
   through several links, it will have corresponding to it the set of
   SRLG values of its member links.   The lightpaths within a
   restoration group cannot share the same set of SRLG value, as then a
   single failure could affect several lightpaths simultaneously.
   Therefore, when a new lightpath is created, if it cannot be placed
   within any existing restoration group, a new restoration group is
   created, along with a backup lightpath for the newly created primary
   lightpath.

   The difference between a primary lightpath and backup lightpath is
   that the backup lightpath has no connections between the data port
   and lambda port in the OXCs of the ingress router and egress router,
   whereas the primary lightpath has both of them.  The connections
   between these ports are made during the restoration process.



Hahm et al                                                      [Page 5]


draft-hahm-optical-restoration-00.txt                      November 2000



o Release of damaged lightpath

   A damaged lightpath must be released in order to make its (undamaged)
   resources available to newly created lightpaths.  The release of
   lightpath resources is the ingress OXC's responsibility.  The
   released resources can be reused after announcement of their released
   status via OSPF or IS-IS LSAs.


o Failure of lightpath creation

   The creation of lightpaths can fail for the following three reasons.
   First, failure can occur due to an inconsistency between the gathered
   link state information at the ingress OXC and the actual link status
   of optical network. Because link state information is only
   transmitted periodically from every OXC, delayed updates can make for
   this inconsistency.

   Secondly, failure can occur even if link state information is
   consistent with the actual link status.  If two ingress OXCs decide
   simultaneously to use the same network resources, one of the
   lightpath setup attempts will fail because its resources have already
   been claimed by the other lightpath.

   Finally, even if lightpath establishment completes, the lightpath may
   fail to carry data because the quality of transmission does not reach
   the threshold level.  The deterioration of transmission quality can
   occur due to several reasons[7,8].

   The first two cases of failure during lightpath setup are reported to
   the ingress OXC by a lightpath notification message from the
   intermediate OXC where the error is noted.

   Failure of the last sort can be detected by measuring the SNR of the
   received optical signal, or the error ratio of Optical-to-Electric
   transformed data.  If the quality of the lightpath does not reach the
   threshold level, the lightpath is released, and a new lightpath is
   created.


4. Procedures for bandwidth provisioning and restoration

   In this section, the procedures for bandwidth provisioning and
   restoration are described in detail, which include the setup
   procedures for primary and backup lightpath, the reporting procedure
   for handling damaged lightpaths, the restoration procedure for
   replacing a damaged lightpath with the backup lightpath, and the
   release procedure for unused lightpaths.


4.1 Decision of lightpath based on link state information


Hahm et al                                                      [Page 6]


draft-hahm-optical-restoration-00.txt                      November 2000


   If the primary lightpath cannot be created within an existing
   restoration group, after creating a new restoration group, the
   primary lightpath and backup lightpath are created within the newly
   created restoration group.  If the primary lightpath can be created
   within an existing restoration group, no new backup lightpath needs
   to be created, so the primary lightpath only is created.


4.1.1 Lightpath setup procedure for primary lightpath

   Once the route of a lightpath is decided, the ingress OXC sends the
   Lightpath Setup Message to the next intermediate OXC through the
   control channel.  The  sequence of intermediate OXCs and the lambdas
   to be allocated for the lightpath are stored in the lightpath setup
   message.

   An intermediate OXC receives the lightpath setup message from its
   adjacent OXC. The OSC of the intermediate OXC then attempts to
   configure the OXC switch fabric according to the lightpath setup
   message, and receives the result from the OXC switch fabric.  If a
   successful result is returned, the OSC of the intermediate OXC then
   removes its OXC identifier from the lightpath setup message, and then
   transmits the modified lightpath setup message to the next adjacent
   intermediate OXC.  During this procedure, intermediate OXCs consume
   the network resources and therefore update the link state
   information. This link state information will then be distributed to
   other OXC at the next period by using OSPF or IS-IS LSAs.

   If a lightpath setup message successfully reaches the egress OXC, the
   egress OXC then returns the lightpath notification message noting the
   successful lightpath creation to the ingress OXC.  Upon receiving
   this notification message, the ingress OXC announces this increment
   in available bandwidth capacity by using OSPF or IS-IS LSA functions
   at the IP level.  Routers receiving this link status information can
   then apply the increased bandwidth to provisioning of LSPs meeting
   traffic engineering requirements.

   If an intermediate OXC receiving the lightpath setup message cannot
   successfully configure the OXC switch fabric, the intermediate OXC
   replies with a lightpath notification message indicating the failure
   to the ingress OXC.  An ingress OXC receiving this reply then sends a
   lightpath release message to release any tentatively claimed
   resources.  The detailed procedure is explained in section 4.3.

   The primary lightpath made by this procedure has a lightpath ID
   comprising the ingress OXC identifier, a B flag value of 0 indicating
   that this lightpath is a primary lightpath, and the outgoing lambda
   port in the ingress OXC.  This lightpath ID is then used to identify
   the lightpath in subsequent messages related to lightpath failure,
   restoration, and release.




Hahm et al                                                      [Page 7]


draft-hahm-optical-restoration-00.txt                      November 2000


4.1.2 Lightpath setup procedure for backup lightpath

   Backup lightpaths are created through the same procedure as primary
   lightpaths.  The backup lightpath made by this procedure has a
   lightpath ID comprising the ingress OXC identifier, a B flag value of
   1 indicating that this lightpath is a backup lightpath, and the
   sequence number issued by the ingress OXC. This lightpath ID is then
   similarly used to indicate the lightpath in subsequent messages.


4.2 Procedure for reporting a damaged lightpath

   Damage to lightpaths can be detected by the egress OXC.  After
   detection, the egress OXC issues a lightpath failure message as soon
   as possible.  The lightpath failure message comprises the ID of the
   damaged primary or backup lightpath, and the reason why the
   impairment occurred.


4.3 Restoration procedure

   Restoration can be applied to a damaged primary lightpath or backup
   lightpath.

4.3.1 Restoration procedure for damaged primary lightpath

   In case of failure of a primary lightpath, the ingress OXC is made
   aware of which lightpath is damaged by the lightpath ID in the
   failure message.  The ingress OXC then replaces the damaged primary
   lightpath with the backup lightpath sharing the same restoration
   group.

   First of all, the ingress OXC repairs the connection within its own
   OXC by replacing the connection between the incoming data port and
   outgoing lambda port of the damaged lightpath with the connection
   between the incoming data port and outgoing lambda port of the backup
   lightpath.  This process is executed internally without exchanging
   messages.

   As the second step, the ingress OXC issues the lightpath restoration
   message.  This message has the information of the egress OXC
   identifier and the OXC outgoing data port ID to be connected to
   backup lightpath. If the egress OXC receives this message, the OSC of
   egress OXC converts this message into the control command to control
   the connection in OXC switch fabric, and sends this control to OXC
   switch fabric.  The OXC switch fabric responses the executed result
   to the OSC, and the egress OXC of OSC reflects the result to the
   lightpath notification message, and sends this message to the ingress
   OXC.

   Because the backup lightpath is consumed by this restoration
   procedure, the new alternative backup lightpath must be created.


Hahm et al                                                      [Page 8]
   

draft-hahm-optical-restoration-00.txt                      November 2000


   This procedure is carried out after the procedure of section 4.1.2.


4.3.2 Restoration procedure for damaged backup lightpath

   In case of failure of backup lightpath, ingress OXC can be aware
   which lightpath is damaged by referring the lightpath ID of the
   backup lightpath.

   The damage of the backup lightpath does not affect to the ongoing
   data transfer.  However, because the primary lightpaths belonging to
   the same restoration group lose the restoration capability, the
   alternative backup lightpath must be created as soon as possible.
   The procedure for creating alternative backup lightpath is processed
   according to the procedure of section 4.1.2.

4.4 Lightpath release procedure for lightpath

   The release of lightpath takes place against the following
   lightpaths: (1) the primary or backup lightpath impaired due to the
   damage, (2) the primary lightpath that is not used any longer due to
   the decreased volume of the data traffic, (3) the backup lightpath
   becoming useless due to the release of all primary lightpaths sharing
   the same restoration group, (4) the primary or backup lightpath that
   is not proceed its lightpath further due to the occurrence of the
   error during the lightpath setup procedure.

   The lightpath release message is transmitted to the egress OXC or the
   intermediate OXC from the ingress OXC passing through the
   intermediate OXCs comprising the target lightpath.  In order to do
   this processing, the lightpath release message has the information of
   the sequence of intermediate OXCs that it has to travel and the
   lambdas to be de-allocated.

   An intermediate OXC receives the lightpath release message from its
   adjacent OXC. The OSC of the intermediate OXC then attempts to
   configure the OXC switch fabric according to the lightpath release
   message, and receives the result from the OXC switch fabric.  If a
   successful result is returned, the OSC of the intermediate OXC then
   removes its OXC identifier from the lightpath release message, and
   then transmits the modified lightpath release message to the next
   adjacent intermediate OXC.  During this procedure, intermediate OXCs
   bring back the network resources and therefore update the link state
   information. This link state information will then be distributed to
   other OXC at the next period by using OSPF or IS-IS LSAs.

   If finally the lightpath release message is proceeded to the egress
   OXC with success, the egress OXC replies the successful release to
   the ingress OXC by the lightpath notification message, and the
   ingress OXC receiving the notification message announces the
   decrement of bandwidth capacity by using OSPF or IS-IS LSA function
   at the IP level.  The routers receiving this link status information


Hahm et al                                                      [Page 9]
  

draft-hahm-optical-restoration-00.txt                      November 2000


   apply the increased bandwidth to the allocation of LSP considering
   the traffic engineering requirement.

   If the intermediate OXC receiving the lightpath release message fails
   to control of the OXC switch fabric, it receives the response of
   failure from OXC switch fabric, the intermediate OXC replies the
   error and the reason why failure occurs to the ingress OXC by using
   the lightpath notification message.


5. Message Types

   In this section, we define the message types which are used for the
   bandwidth provisioning and restoration procedures.

5.1 Lightpath Setup Message

   Lightpath Setup message is issued to create primary lightpath or
   backup lightpath by an ingress OXC.  This message is forwarded to the
   next intermediate OXC through a control channel on the hop by hop
   basis.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|         Lightpath Setup     |     Message Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Message ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Ingress OXC identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |B|  OXC Outgoing Lambda Port ID (pri) or Sequence Number(bak)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Lightpath OXC list TLV                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Egress OXC identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OXC Outgoing Data Port ID (primary) or Null (backup)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      - Message ID
        The message identifier of this message, which is incremented by
        one whenever a new message is generated by this ingress OXC,
        regardless the generated message type. It is used to specify the
        message issued by ingress OXC to create the lightpath.

      - Ingress OXC identifier
        The address of ingress OXC at which a lightpath starts.

      - B
        If the created lightpath is a backup lightpath, B is set to 1.
        Otherwise(a primary path), it is set to 0.


Hahm et al                                                     [Page 10]


draft-hahm-optical-restoration-00.txt                      November 2000


      - OXC Outgoing Lambda Port ID
        If the created lightpath is a primary lightpath, this represents
        an ID of outgoing lambda port from which the lightpath starts.

      - Sequence Number
        If the created lightpath is a backup lightpath, it is used to
        identify the lightpath.  In general, this value is increased by
        one whenever it is issued by ingress OXC.  If the increased
        value is the same as the one that is still used for a existing
        backup lightpath, the sequence number increased again to the
        next higher value.

        The value of { Ingress OXC identifier + B + OXC outgoing lambda
        Port ID | Sequence Number } is unique through out the optical
        network. Therefore, this combined value is used to specify the
        lightpath.

      - Lightpath OXC list TLV
        It represents the sequence of OXCs comprising lightpath and
        lambdas being allocated for a lightpath.

      - Egress OXC Identifier
        The identifier of the OXC at which the lightpath ends.

      - OXC Outgoing Data Port ID
        If the lightpath is a primary lightpath (B=0), this field is
        filled by outgoing data port ID. Otherwise (B=1), this field is
        set to zero.


5.2  Lightpath Notification Message

   This message is used as the response message for the Lightpath Setup
   Message, the Lightpath Restoration Message, and the Lightpath Release
   Message. An ingress OXC identifies a response message respectively by
   comparing the Message ID conveyed by a notification message with the
   Message ID which was issued by itself.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|       Lightpath Notify      |       Message Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Message ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Returned OXC identifier                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Result                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      - Message ID
        This message ID is the return value of the message ID which is


Hahm et al                                                     [Page 11]
      

draft-hahm-optical-restoration-00.txt                      November 2000


        generated by ingress OXC. This ID is used to identify the 
        original message respectively.

      - Returned OXC identifier
        The IP address of the intermediate OXC or egress OXC which
        issued this Notification message.

      - Result
        0: The message which was issued by an ingress OXC is processed
           successfully
        1: The designated intermediate OXC does not exist
        2: The designated fiber does not exist in the designated
           intermediate OXC
        3: The designated lambda does not exist in the designated
           intermediate OXC
        4: The outgoing Data port does not exist in the designated
           egress OXC
        5: The lambda switching function does not exist in OXC
        6: The lambda conversion function does not exist in OXC
        7: The outgoing data port of the designated OXC is used by
           another primary lightpath
        8: The release of designated lightpath was failed
        9: The restoration of designated lightpath was failed
       10: Error occurred by an unspecified reason


5.3  Lightpath Failure Message

   This message is generated by an egress OXC to notify error status of
   a lightpath. The ingress OXC can identify which lightpath is under
   malfunction by the lightpath ID of this message.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|      Lightpath Failure      |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Message ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Ingress OXC Identifier                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |B|  OXC Outgoing Lambda Port ID (pri) or Sequence Number(bak)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Egress OXC Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Result                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      - Message ID
        The message identifier of this message, which is incremented by
        one whenever a new message is generated by this egress OXC,
        regardless the generated message type. It is used to specify the


Hahm et al                                                     [Page 12]


draft-hahm-optical-restoration-00.txt                      November 2000


        message issued by egress OXC to inform the damaged lightpath.


      - Lightpath ID
        { Ingress OXC identifier + B + OXC outgoing lambda Port ID |
        Sequence Number } is used to specify the lightpath

      - Egress OXC Identifier
        Address of Egress OXC which detected the damage of a lightpath

      - Result
        1: Signal of light was disappeared
        2: Signal level of light was degraded
        3: Error rate of transmitted data exceeded threshold level
        4: Error occurs with an unspecified reason


5.4  Lightpath Restoration Message

   This message is sent to an egress OXC by an ingress OXC to restore a
   damaged primary lightpath or damaged backup lightpath.  When an
   ingress OXC receives the lightpath failure message from egress OXC,
   it issues this message.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|     Lightpath Restore       |       Message Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Message ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Ingress OXC Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|                  Sequence Number (backup)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Egress OXC Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    OXC Outgoing Data Port ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      - Message ID
        The message identifier of this message, which is incremented by
        one whenever a new message is generated by this ingress OXC,
        regardless the generated message type. It is used to specify the
        message issued by ingress OXC to restore the damaged lightpath.

      - Lightpath ID
        { Ingress OXC identifier + 1 + Sequence Number } is used to
        specify the backup lightpath

      - Egress OXC Identifier
        Address of Egress OXC which detects the damage of a lightpath


Hahm et al                                                     [Page 13]


draft-hahm-optical-restoration-00.txt                      November 2000


      - OXC Outgoing Data Port ID
        It is the port ID in egress OXC to which a backup lightpath
        is connected.

5.5  Lightpath Release Message

   This message is used to release the established primary lightpath or
   backup lightpath.  If the intermediate OXCs or egress OXC receive
   this message, they release the lambda or outgoing data port
   resources.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|      Lightpath Release      |          Message Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Message ID                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Ingress OXC identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |B|  OXC Outgoing Lambda Port ID (pri) or Sequence Number(bak)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Lightpath OXC list TLV                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Egress OXC identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OXC Outgoing Data Port ID (primary) or Null (backup)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      - Message ID
        The message identifier of this message, which is incremented by
        one whenever a new message is generated by this ingress OXC,
        regardless the generated message type. It is used to specify the
        message issued by ingress OXC to release the pre-occupied
        lightpath.

      - Lightpath Identifier
        {Ingress Router IP Address + B + Router Output Port ID |
        Sequence Number} is used to identify the primary lightpath or
        backup lightpath which is released by an ingress OXC

      - Lightpath OXC list TLV
        Represents the sequence of OXCs comprising released lightpath
        and lambdas being allocated for a lightpath

      - Egress OXC Identifier
        The identifier of the OXC at which a lightpath ends.

      - OXC Outgoing Data Port ID
        If the lightpath is a primary lightpath (B=0), this field is
        filled by outgoing data port ID. Otherwise (B=1), this field is


Hahm et al                                                     [Page 14]


draft-hahm-optical-restoration-00.txt                      November 2000


      set to zero.

5.6 Lightpath OXC List TLV

   This TLV is used to specify a sequence of the OXCs which are
   connected by optical links and lambdas. This TLV is used with the
   Lightpath Setup Message and Lightpath Release Message. The listed
   OXCs is listed from the nearest OXC to the farthest OXC.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|  Type(= Lightpath OXC list) |       Length = 8 * n          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       OXC Identifier #1                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Outgoing Fiber ID       |     Outgoing Lambda ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          . . . . . .                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          . . . . . .                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       OXC Identifier #n                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Outgoing Fiber ID       |     Outgoing Lambda ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      - OXC Identifier
        It is used to identify a OXC that lies on the lightpath

      - Outgoing Fiber ID
        It is used to identify an outgoing fiber from the specified OXC

      - Outgoing Lambda ID
        It is used to designate a lambda assigned to the specified fiber


Security Considerations

   It is of course essential to maintain secure communication between
   the OXCs. However, this document does not address the detailed
   security consideration. It is reserved for future study.


References


   [1] Daniel O. Awduche, Yakov Rekhter, John Drake, and Rob Coltun,
       "Multi-Protocol Lambda Switching: Combining MPLS Traffic
       Engineering Control with Optical Crossconnect," Internet Draft,
       Work in Progress, November 1999



Hahm et al                                                     [Page 15]


draft-hahm-optical-restoration-00.txt                      November 2000


   [2] Kireeti Kompella et al, "Extensions to IS-IS/OSPF and RSVP in
       support of MPL(ambda)S," Internet Draft, Work in Progress,
       February,2000

   [3] S. Giacalone, "Network Engineering Extensions (NEXT) for OSPFv3,"
       Internet Draft, Work in Progress, August 2000

   [4] G. Wang et al, "Extensions to OSPF/IS-IS for Optical Routing,"
       Internet Draft, Work in Progress, March 2000

   [5] K. Kompella et al, "IS-IS Extensions in Support of MPL(ambda)S,"
       Internet Draft, Work in Progress, July 2000

   [6] K. Kompella et al, "OSPF Extensions in Support of MPL(ambda)S,"
       Internet Draft, Work in Progress, July 2000

   [7] Angela Chiu and John Strand, "Unique Features and requirements
       for the Optical Layer Control Plane," Internet Draft, Work in
       Progress, July 2000

   [8] L. Ceuppens, D. Blumenthal, J. Drake, J. Chrostowski, and W.
       Edwards, "Performance Monitoring in Photonic Networks in support
       of MPL(ambda)S," Internet Draft, Work in Progress, March 2000



Acknowledge

   This work has been produced from the joint project between ETRI
   (Electronics and Telecommunications Research Institute in Korea) and
   NIST (National Institute Standards and Technology).


Author's Address

   Jin Ho Hahm
   ETRI
   820 West Diamond Avenue
   Gaithersburg, MD 20899
   Phone: 301-975-8400
   Email: hahm@antd.nist.gov & jhhahm@etri.re.kr

   Kwang-il Lee
   NIST
   820 West Diamond Avenue
   Gaithersburg, MD 20899
   Phone: 301-975-8428
   Email: kilee@antd.nist.gov






Hahm et al                                                     [Page 16]