[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
                                             Bala Rajagopalan
Internet Draft                               Debanjan Saha
draft-bala-restoration-signaling-01.txt         Tellium, Inc.
Expires on: 2/20/2002                        Greg Bernstein
                                                Ciena Corp.
                                             Vishal Sharma
                                                Metanoia, Inc




        Signaling for Fast Restoration in Optical Mesh Networks


Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   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.


1. Abstract

   Restoration of switched connections under tight time constraints is
   a challenging problem in optical mesh networks. This draft describes
   different protection modes for connections under both local and end-
   to-end restoration scenarios, and defines lightweight protocol
   mechanisms (over IP) for restoration-related signaling.


2. Introduction

   Restoration of switched connections under tight time constraints is
   a challenging problem in optical mesh networks. Such a network
   consists of optical cross-connects (OXCs) connected in a general
   topology [1]. Restoration typically involves the activation of an
   alternate path for a connection when a failure is encountered in the


                         Expires on 2/20/2002                   Page 1

               draft-bala-restoration-signaling-01.txt


   primary path. A path for a connection (primary or alternate) is
   characterized by an ingress port, an egress port, and a set of
   intermediate OXCs and links through which the connection is routed.
   The ingress and egress port remain the same for primary and
   alternate paths, but the rest of the paths are typically resource-
   disjoint (e.g., node or link disjoint).

   A bi-directional link between neighboring OXCs is usually realized
   as a pair of unidirectional links. The end-to-end path for a bi-
   directional connection therefore consists of a series of bi-
   directional links between the source and destination OXCs,
   traversing intermediate OXCs.

   The manner in which restoration is accomplished depends on the type
   of protection afforded to the connection. In this regard, protection
   can be "local span" or "end-to-end". Local span protection refers to
   the protection of the connection segment between two neighboring
   switches. End-to-end protection refers to the protection of the
   entire connection from the ingress to the egress port. A connection
   may be subject to both local span protection (for each of its
   segments) and end-to-end protection (when local protection does not
   succeed). Under local span and end-to-end protection schemes, it may
   be required that when a failure affects any one direction of the
   connection, both directions of the connection are switched to a new
   link or path, respectively. In the following, therefore, any
   reference to a "link" indicates a bi-directional link (realized as a
   pair of uni-directional links).

   Considering local-span protection, suppose a connection segment is
   routed over link i between two OXCs A and B. The following
   protection modes may be used:

        1+1 (unidirectional): A dedicated alternate link j is pre-
        assigned to protect link i. Connection traffic is
        simultaneously sent on both links and received from one of the
        functioning link, i or j.

        1+1 (bi-directional): A dedicated alternate link j is pre-
        assigned to protect link i. Connection traffic is
        simultaneously sent on both links and under normal conditions,
        the traffic from link i is received by OXCs A and B (in the
        appropriate directions). A failure affecting link i results in
        both A and B switching to the traffic on link j in the
        respective directions.

        1:M: A dedicated link j between A and B is pre-assigned to
        protect a set of M links (which includes i). A failure
        affecting any link in this set results in the corresponding
        traffic being restored to link j. Clearly, if more than one
        link in the set of M links are concurrently affected by
        failures, the traffic on only one of them may be restored over
        link j.


                          Expires on 2/20/02                    Page 2

               draft-bala-restoration-signaling-01.txt


        M:N (with pre-configured protection groups): A protection group
        of M+N links consists of a set of M links protected by a set of
        N links, with N < M. (Link i must be one of the M links in a
        protection group, and link j is one of the N links). A failure
        in any of the M links results in traffic being switched to one
        of the (available) N links. The number of protection groups
        between A and B, the value of M and N, as well as the specific
        links in each protection group is pre-configured. Since N < M,
        it is possible that not all failed links in the set of M links
        may be protected from the same failure event.

        M:N (pooled protection links): Under this mode, a total of N
        links are assigned to protect a total of M other links betwen A
        and B, where M+N is the total number of links between A and B.
        (Link i must be one of the set of M links, and link j is one of
        the set of N links). The value of M and N is pre-configured,
        and the specific links in the set of N protection links may
        also be pre-configured. As before, since N < M, it is possible
        that not all failed links in the set of M links may be
        protected from the same failure event.

   With SONET links, 1+1, 1:M and M:N with pre-configured protection
   groups are typically realized using SONET protocols. In this draft,
   we therefore focus on M:N protection with pooled protection links.
   This sort of protection requires a higher layer signaling protocol,
   as defined in this draft later.

   Considering end-to-end protection, suppose a connection's primary
   (bi-directional) path is from an ingress port in OXC A to an egress
   port in OXC B over a set of intermediate OXCs. The following
   protection modes may be used:

   1+1 (unidirectional): A dedicated, resource-disjoint alternate path
   is pre-established to protect the connection. Connection traffic is
   simultaneously sent on both paths and received from one of the
   functional paths by the end OXCs, A and B.

   1+1 (bi-directional): A dedicated, resource-disjoint alternate path
   is pre-established to protect the connection. Connection traffic is
   simultaneously sent on both paths and under normal conditions, the
   traffic from the primary path is received by OXCs A and B (in the
   appropriate directions). A failure affecting the primary path
   results in both A and B switching to the traffic on the back-up path
   in the respective directions

   Shared: An alternate path is pre-assigned to protect the connection,
   but the links along the alternate path are shared among multiple
   connections being protected. In this case, the links are allocated
   in real-time for one of the protected connections whose primary path
   is affected by a failure. If more than one such connection is
   concurrently affected by a failure, only one of them will be allowed
   to use a shared link.


                          Expires on 2/20/02                    Page 3

               draft-bala-restoration-signaling-01.txt


   New protocols are required to realize both 1+1 (bi-directional) and
   shared end-to-end protection in optical mesh networks. Specifically,
   1+1 (bi-directional) protection requires coordination between the
   end OXCs to switch to the protection path, and shared protection
   additionally involves the intermediate OXCs in the protection path.

   The aim of this draft is to define the signaling protocols for both
   M:N pooled local span protection and the two end-to-end protection
   modes, 1+1 (bi-directional) and shared. The main requirements on
   these protocols are simplicity and speed. The latency requirement on
   switching to protection paths is typically specified in tens to
   hundreds of milliseconds, the performance depending on the number of
   hops involved. It is clear that a protocol level specification
   itself cannot guarantee these performance numbers, since a lot
   depends on the system architecture of the OXCs that implement the
   protocols. Indeed, this is the reason why these protocols are
   presently being implemented in a proprietary manner. It is, however,
   a reasonable goal to aim for a lightweight protocol mechanism that
   has a good chance of achieving the target performance. This is
   precisely the objective of this draft. Given the fact that IP-
   centric (GMPLS) protocols have been widely accepted for provisioning
   of primary and back-up paths, it is natural to consider standard,
   IP-based restoration protocols to move away from proprietary
   restoration solutions.

   In the next section, the basic signaling mechanism proposed for fast
   restoration is outlined. Sections 4 and 5 describe local span and
   end-to-end protection protocols in detail. Section 6 presents some
   discussion items and Section 7 presents the conclusions.



3. Signaling Mechanism

3.1  Description

   As described in the next two sections, the signaling protocols for
   local and end-to-end protection rely on a small set of short
   messages. A question that arises is whether an existing protocol
   framework could be used for supporting such messages. For instance,
   it is conceivable that RSVP-TE or CR-LDP protocols may be extended
   to support restoration signaling in the same way they are used for
   provisioning. In our view, restoration signaling must be given the
   highest priority and presently, there is no means to give relative
   priorities to different RSVP or CR-LDP messages (if used for both
   provisioning and restoration). Furthermore, our desire is to specify
   a lightweight protocol not encumbered by any of the RSVP or LDP
   semantics. Indeed, even if these protocols are extended for
   restoration signaling, they will in essence implement a logically
   distinct protocol framework for restoration as compared to signaling
   for provisioning. In this sense, it seems best to start with a new
   protocol dedicated for restoration signaling. This is indeed the
   proposal made in this draft.

                          Expires on 2/20/02                    Page 4

               draft-bala-restoration-signaling-01.txt



   To main aspects of the proposed signaling mechanism are as follows:

   o    The signaling mechanism consists of new protocol running
        directly on top of IP

   o    The signaling mechanism supports a small set of messages, each
        of which is succinct, transported in a single short IP packet

   o    The signaling mechanism supports reliable delivery via a simple
        retransmission mechanism

   o    Signaling messages are sent over the IP control channel between
        neighboring OXCs. This control channel can be in-band or out-
        of-band.

   As per this proposal, an implicit peering relationship exists
   between protocol instances in two OXCs when the OXCs are topological
   neighbors in the data plane. Such a pair of OXCs must have one or
   more control channels between them, in-band or out-of-band. The
   number of protocol instances running in an OXC, and how the
   signaling pertaining to different connections are distributed within
   an OXC would depend on the system architecture. These details are
   beyond the scope of this draft.

   The general format of signaling messages under this proposal is
   given below:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                     |
     //                IP Header (20 Octets)              //
     |                                                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type    |  Length     |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                  Data  (Variable)                 //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The source and destination address in the IP header are set to the
   sending OXC and the (neighboring) receiving OXC. The protocol ID in
   the IP header is set to the (yet unassigned) new value corresponding
   to the restoration protocol.

   The restoration message types and data are as defined in the
   following sections. The 16-bit checksum field covers the entire
   restoration message, starting from the type field. The Length field
   indicates the number of 4-octet words in the message, starting with
   the Type field.




                          Expires on 2/20/02                    Page 5

               draft-bala-restoration-signaling-01.txt


3.2  Applicability

   The proposed signaling protocols for local span and end-to-end
   protection are intended to be applicable in both networks of O-E-O-
   type OXCs or all-optical OXCs. Because of the emphasis on bi-
   directional connections, the 1+1 protection procedures as described
   in this draft may not be relevant in general MPLS networks. Because
   of the need to configure intermediate OXCs in real-time for end-to-
   end shared protection, this procedure is also not applicable in
   general MPLS networks.


4. Local Span Protection

   Local span protection is described with respect to two neighboring
   OXCs A and B. The scenario considered for local span protection is
   as follows:

   o    At any point in time, there are two sets of links between A and
        B, i.e., a "working" set of M (bi-directional) links carrying
        traffic subject to protection and a "free" set of N (bi-
        directional) links. A free link may have no traffic on it, or
        it may be carrying preemptable traffic. There is no apriori
        relationship between the two sets of links, but the value of M
        and N are pre-configured. The specific links in the free set
        MAY be pre-configured to be physically diverse to avoid the
        possibility that failure events affect a large proportion of
        free links (along with working links).

   o    When a link in the "working" set is affected by a failure, the
        traffic on it is diverted to a link in the "free" set, if such
        a link is available. Note that such traffic might consist of
        more than one connection, for example, an OC-192 link carrying
        four OC-48 connections.

   o    More than one link in the "working" set may be affected by the
        same failure event. In this case, there may not be an adequate
        number of "free" links to accommodate all of the affected
        traffic carried by failed "working" links. The set of affected
        "working" links that are actually restored over available
        "free" links is then subject to policies (e.g., based on
        relative priority of working traffic). These policies are not
        specified in this draft.

   o    Each OXC is assumed to have the mapping of its local link (or
        port) ID to the corresponding ID at the neighbor. This mapping
        could be configured, or obtained automatically using a neighbor
        discovery procedure (e.g., LMP [2]).

   o    When traffic must be diverted from a failed link in the
        "working" set to a "free" link, the decision as to which "free"
        link is chosen is always made by one of the OXCs, A or B. As
        per this draft, the OXC with the numerically larger IP address

                          Expires on 2/20/02                    Page 6

               draft-bala-restoration-signaling-01.txt


        is considered the "master" and it is required to both apply any
        policies and select specific "free" links to divert working
        traffic. The other OXC is considered the "slave". The
        determination of the master and the slave may be based on
        configured information, or the result of running a neighbor
        discovery procedure.

   o    Failure events themselves are assumed to be detected by lower
        layer mechanisms (e.g., SONET). Since the bi-directional links
        are formed by a pair of unidirectional links, a failure in the
        link from A to B is typically detected by B and a failure in
        the opposite direction is detected by A. It is possible that a
        failure simultaneously affects both directions of the bi-
        directional link. In this case, A and B will concurrently
        detect failures, in the B-to-A direction and in the A-to-B
        direction, respectively.

   The basic steps in local span protection are as follows:

   1.   If the master detects a failure of a "working" link, it
        autonomously invokes a process to allocate a "free" link to the
        affected traffic.

   2.   If the slave detects a failure of a "working" link, it must
        inform the master of the failure. The master then invokes the
        same procedure as above to allocate a "free" link. (It is
        possible that the master has itself detected the same failure,
        for example, a failure simultaneously affecting  both
        directions of a link).

   3.   Once the master has determined the identity of the "free" link,
        it indicates this to the slave and requests the switchover of
        the traffic. Prior to this, if the "free" link is carrying
        preemptable traffic, the master stops using the link for this
        traffic (i.e., the traffic is dropped by the master and not
        forwarded into or out of the "free" link).

   4.   The slave sends an acknowledgement to the master. Prior to
        this, if the selected "free" link is carrying preemtable
        traffic, the slave stops using the link for this traffic (i.e.,
        the traffic is dropped by the slave and not forwarded into or
        out of the "free" link). It then starts sending the (failed)
        "working" link traffic on the selected  "free" link.

   5.   When the master receives the acknowledgement, it starts sending
        and receiving the (failed) working link traffic over the new
        link.

   From the description above, it is clear that local span restoration
   requires three messages for each working link being switched: a
   failure indication message, a switchover request message and a
   switchover response message. The following identifier is also
   needed:

                          Expires on 2/20/02                    Page 7

               draft-bala-restoration-signaling-01.txt



4.1  Identifiers

   Link ID: A 32-bit identifier that uniquely identifies a bi-
   directional link at the sending and the receiving OXC. The link ID,
   for instance, could be the port ID at the receiving OXC.

   The messages are as follows.

4.2 Failure Indication Message

   This message is sent from the slave to the master to indicate the
   failure of one or more working links. (This message may not be
   necessary when the underlying link technology itself provides for
   such a notification)

   The format of this message is as follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x01   |  Length     |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                ID of failed link                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                ID of failed link                  //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The number of links included in the message would depend on the
   number of failures detected within a window of time by the sending
   OXC. An OXC may choose to send separate failure indication messages
   in the interest of completing the restoration for a given link
   within an implementation-dependent time constraint.

   The ID of the failed link is the identification used at the slave
   OXC. The master must convert this to the corresponding ID at its
   side.

   This message is transmitted periodically by the slave, as controlled
   by the configurable timer, Retransmission Timer. The default value
   of this timer is 30ms. The slave stops transmitting this message
   under the following conditions:

   o    A corresponding Switchover Request message is received;

   o    The Failure Indication Timer expires (the action in the latter
        case is undefined in this draft. For instance, the sending OXC
        may notify a management system. The default value for this
        timer is 500 ms); or

   o    The connection is de-provisioned.




                          Expires on 2/20/02                    Page 8

               draft-bala-restoration-signaling-01.txt


4.3  Switchover Request Message

   This message is sent from the master to the slave to indicate
   whether the traffic on the failed working link can be switched to a
   free link, and if so, the ID of the free link.

   The format of this message is as follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x02   | Length      |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Message ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                ID of failed link                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                ID of free link                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                ID of failed link                  //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                ID of free link                    //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The link IDs are based on the identification used at the master. The
   slave must convert them to the corresponding local IDs. The message
   ID uniquely identifies the message at the master.

   If the message is generated in response to a Failure Indication
   message from the slave then the set of failed links in the message
   MUST be the same as the set received in the Failure Indication
   message. If the ID of the free link is the same as the ID of the
   failed link then it is implicit that the traffic on the failed link
   cannot be switched to a free link.

   This message is transmitted periodically by the master, as
   controlled by the configurable parameter, Retransmission Timer. The
   default value of this parameter is 30ms. Each retransmitted message
   has the same content, including the Message ID. The master stops
   transmitting this message under the following circumstances:

   o    The Switchover Timer expires (the action in the latter case is
        undefined in this draft. For instance, the master may notify a
        management system. The default value for this timer is 300 ms);
        or

   o    The connection is de-provisioned

   o    The corresponding Switchover Response is received.

   A failure event may result in the master sending more than one
   Switchover Request message to the same slave OXC. In this case, each
   of these messages will have different Message IDs and indicate


                          Expires on 2/20/02                    Page 9

               draft-bala-restoration-signaling-01.txt


   different failed links. The retransmission of each is controlled by
   a different instance of the Retransmission Timer.

4.4  Switchover Response Message

   This message is sent from the slave to the master to indicate the
   receipt of the Switchover Request message.

   The format of this message is as follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x03   |  Length     |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Received Message ID                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               ID of failed link                   //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Received Message ID field is filled with the Message ID received
   in the corresponding Switchover Request message. The failed link ID
   field, if present, indicates that the slave cannot switch over to
   the corresponding free link for some reason. This identification is
   based on the IDs used at the slave. The action to be taken by the
   master when there are one or more failed link IDs in the Switchover
   Response message is undefined (for example, the master may abort the
   switchover of the traffic on the failed working link, and perhaps
   trigger end-to-end protection).

   The slave responds with the appropriate Switchover Response each
   time it receives a Switchover Request Message (including
   retransmitted Switchover Request messages). Of course, the
   switchover action itself must be performed only once by the slave
   for a given failed link.


5.  End-to-End Protection

   One of the significant differences between end-to-end protection and
   local span protection (as considered in this draft) is that the
   latter is on a per-link basis while the former is on a per-
   connection basis. In other words, span protection switches over the
   entire traffic on a link which may consist of multiple connections.
   End-to-end protection, on the other hand, switches over individual
   connections. In this case, there is a "working" connection path and
   a "protection" path.

   Another difference between end-to-end and local protection is that
   signaling messages may have to be transmitted multiple hops to
   effect restoration. The signaling messages are transmitted along the
   connection path, working or protection, where it is assumed that
   there is a control channel between each pair of intermediate OXCs.


                          Expires on 2/20/02                   Page 10

               draft-bala-restoration-signaling-01.txt



   There are two cases to be considered: signaling for bi-directional
   1+1 protection and for shared protection. The description below is
   in the context of an end-to-end connection between a source OXC A
   and a destination OXC B. The source for such a connection is also
   considered to be the "owner" of the connection. The owner is the
   node which initiated the connection establishment or designated when
   the connection is manually provisioned.


5.1  Bi-directional 1+1 Protection

   Under bi-directional 1+1 protection, the connection traffic is being
   sent on both working and protection links by A and B, but received
   only from the working link. After a failure event, signaling between
   A and B is required to ensure that both A and B start receiving from
   the protection link.

   A failure event is detected by a node in the working path. Such a
   node sends a failure indication signal towards the owner (source) of
   the connection along the working path (using signaling described
   below, or mechanisms provided by the lower layer).

   The action when the source OXC is notified of a failure is as
   follows:

   o    Start receiving from the protection path. At the same time,
        send a Switchover Request message along the protection path
        towards the destination OXC. This message is not explicitly
        addressed to the destination OXC, but it carries a connection
        ID which aids intermediate OXCs in forwarding the message along
        the protection path towards the destination.

   The action when the destination OXC receives a Switchover Request
   message is follows:

   o    Start receiving from the protection path. At the same time,
        send a Switchover Response message along the protection path
        towards the source OXC. The forwarding of this message by
        intermediate OXCs is based on the connection identifier
        information.

5.1.1  Identifiers

   Source ID: The IPv4 address of the source OXC (connection owner).
   This is assumed to be unique for OXCs within the scope of the
   restoration domain.

   Connection index: A 32-bit identifier that uniquely identifies a
   connection at the source.




                          Expires on 2/20/02                   Page 11

               draft-bala-restoration-signaling-01.txt


   Together, the Source ID and the Connection index identify a
   connection uniquely within the scope of the restoration domain. This
   combination is referred to as the "Connection ID" for convenience.


5.1.2  Node Data Structure

   Each OXC that is the working or protection path of a connection must
   maintain a table whose entries consist of the following information:

   <Connection ID (source ID, connection index), Previous OXC,  Next
   OXC, Protection Type>

   The Previous and Next OXC fields are 32-bit IPv4 addresses of
   neighboring OXCs. These are the same addresses used in the IP header
   of restoration messages sent to these neighbors.

   At the source and destination OXCs, the Previous and Next OXC values
   are both set to indicate the same neighbor towards the other
   endpoint of the connection.

   The Protection Type field indicates whether 1+1 or Shared protection
   is being provided for the connection.

   This table may be built when the working and protection paths of the
   connections are provisioned using signaling, or may be configured in
   the case of NMS-based provisioning. The table entries must remain
   until the connection is explicitly de-provisioned.

5.1.3  End-to-End Failure Indication Message

   This message is sent by an intermediate node towards the source of a
   connection along the working path of the connection. For instance,
   such a node might have attempted local span protection and failed
   (this message may not be necessary if the lower layer provides
   mechanisms for detection of connection failure by the endpoints).

   The format of this message is as follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x04   |  Length     |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Connection ID (Source ID)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Connection ID (Connection Index)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Consider an OXC detecting a link failure. Suppose the failed span is
   to a neighbor whose identity is N. The OXC retrieves all table
   entries where N is the Previous or Next OXC. Each such table entry


                          Expires on 2/20/02                   Page 12

               draft-bala-restoration-signaling-01.txt


   indicates the affected connection, and the above message is
   generated for each connection. The message is sent in an IP packet
   with the source address set to the address of the sending OXC and
   the destination address set to the Previous OXC.

   This message is transmitted periodically by the OXC, as controlled
   by the configurable parameter, End-to-End Retransmission Timer. The
   default value of this parameter is 90ms. The OXC stops transmitting
   this message under the following conditions:

   o    A corresponding Failure Acknowledge message is received;

   o    The End-to-End Failure Indication Timer expires (the action in
        the latter case is undefined in this draft. For instance, the
        sending OXC may notify a management system. The default value
        for this timer is 1 minute); or

   o    The connection is de-provisioned.


   Each OXC in the working path receiving such a message does the
   following.

   -    If it is the source of the indicated connection, it stops
        propagating the message further and generates an
        acknowledgement message (Sec. 5.1.4).

   -    If it also has originated a failure indication message for the
        same connection, it stops re-transmitting such a message.
        Furthermore, it also does not propagate the received  failure
        indication message further. (This action is needed when a bi-
        directional data link failure occurs between two OXCs, say, A
        and B. Suppose A is upstream from B (in relation to the
        connection source). Also suppose that A has generated a failure
        indication towards the source. If it later receives a failure
        indication generated by B, it must suppress the retransmission
        of failure indication messages it originated. Also, it need not
        forward the first failure indication message originated by B.
        Finally, it must forward failure indication acknowledge
        messages received from the source to B (Section 5.1.4)).

   -    Otherwise, it looks up the table entry corresponding to the
        Connection ID.

        o       If there is no table entry, the received message is
                silently discarded.

        o       Otherwise, the Source Address in the IP header of the
                message is compared with the Next OXC field: If there
                is a match then the received message is sent in an IP
                packet to the Previous OXC, with Source Address set to
                the address of the sending OXC and Destination Address


                          Expires on 2/20/02                   Page 13

               draft-bala-restoration-signaling-01.txt


                set to Previous OXC. If there is no match, the received
                message is silently discarded.


5.1.4  End-to-End Failure Acknowledge Message

   This message is sent by the source OXC in response to an End-to-End
   failure indication message. This message is sent towards the
   originator of the failure indication message along the working path
   of the connection.

   The format of this message is as follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x05   | Length      |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Connection ID (Source ID)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Connection ID (Connection Index)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This message is transmitted in response to each End-to-End Failure
   Indication message. The source OXC always sends this message to the
   Next OXC as found in the table entry corresponding to the Connection
   ID.

   Each intermediate OXC receiving such a message does the following.

   -    If it is the originator of the corresponding Failure Indication
        message, it stops propagating the message further.

   -    Otherwise, it looks up the table entry corresponding to the
        Connection ID.

        o       If there is no table entry, the received message is
                silently discarded.

        o       Otherwise, the Source Address in the IP header of the
                message is compared with the Previous OXC field: If
                there is a match then the received message is sent in
                an IP packet to the Next OXC, with Source Address set
                to the address of the sending OXC and Destination
                Address set to Next OXC. If there is no match, the
                received message is silently discarded.


5.1.5  End-to-End Switchover Request Message

   This message is generated by the source OXC receiving an indication
   of failure in a connection. It is sent to the Next OXC along the
   protection path.


                          Expires on 2/20/02                   Page 14

               draft-bala-restoration-signaling-01.txt


   The format of this message is as follows:


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x06   |   Length    |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Connection ID (Source ID)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Connection ID (Connection Index)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Status                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The Status field is set to 0x01 if the end OXC is able to switchover
   to the protection path. Otherwise, it is set to 0x00.

   This message is transmitted periodically by the end OXC, as
   controlled by the configurable parameter, End-to-End Retransmission
   Timer. The default value of this parameter is 90ms. The OXC stops
   transmitting this message under the following conditions:

   o    A corresponding End-to-End Switchover Response message is
        received;

   o    The End-to-End Switchover Timer expires (the default value for
        this timer is 1 minute); or

   o    The connection is explicitly de-provisioned.
   Each intermediate OXC receiving such a message does the following.
   It looks up the table entry corresponding to the Connection ID:

   o    If there is no table entry, the received message is silently
        discarded.

   o    Otherwise, if the protection type for the connection is 1+1
        then

        -       the Source Address in the IP header of the message is
                compared with the Previous OXC field: If there is a
                match then the received message is sent in an IP packet
                to the Next OXC, with Source Address set to the address
                of the sending OXC and Destination Address set to Next
                OXC. If there is no match, the received message is
                silently discarded.


5.1.6  End-to-End Switchover Response Message

   This message is sent by the destination OXC receiving an End-to-End
   Switchover Request message. It is sent to the previous OXC in the
   protection path.


                          Expires on 2/20/02                   Page 15

               draft-bala-restoration-signaling-01.txt



   The format of this message is as follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x07   |   Length    |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Connection ID (Source ID)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Connection ID (Connection Index)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Status                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   This message is transmitted in response to each End-to-End
   Switchover Request message received. If the Status field was set to
   0x00 in the Request message, it is set to 0x00 in this message also.
   Otherwise, the Status field is set to 0x01 or 0x00 depending on
   whether the sending OXC is able to switchover to the protection path
   or not, respectively.

   Each intermediate OXC receiving such a message does the following.
   It looks up the table entry corresponding to the Connection ID:

   o    If there is no table entry, the received message is silently
        discarded.

   o    Otherwise, if the protection type for the connection is 1+1
        then

        -       the Source Address in the IP header of the message is
                compared with the Next OXC field: If there is a match
                then the received message is sent in an IP packet to
                the Previous OXC, with Source Address set to the
                address of the sending OXC and Destination Address set
                to Previous OXC. If there is no match, the received
                message is silently discarded.


5.2  Shared Protection

   Shared protection requires prior soft-reservation of capacity along
   the protection path. Furthermore, after a failure event, the
   protection path must be explicitly activated. This requires actions
   at each intermediate OXC along the protection path. It is possible
   that a protection path may not be successfully activated when
   multiple, concurrent failure events occur. In this case, shared
   protection capacity may be claimed for more than one failed
   connection and the protection path can be activated only for one of
   them (at most).



                          Expires on 2/20/02                   Page 16

               draft-bala-restoration-signaling-01.txt


   For implementing shared protection, the identifier and data
   structures related to signaling along the control path are as
   defined for 1+1 protection in Sections 5.1.1 and 5.1.2. In addition,
   each OXC must also keep information needed to establish the data
   plane of the protection path. This information indicates the cross-
   connect that must be established to activate the protection path for
   each connection, as follows:

   {    Connection ID, <Incoming Port, Channel etc>, <Outgoing Port,
        Channel, etc>
   }

   The precise nature of the Port, Channel, etc. information would
   depend on the type of OXC and connection (The Generalized MPLS
   signaling draft describes different type of switches [3]).


5.2.1  End-to-End Failure Indication and Acknowledgement

   The End-to-End failure indication and acknowledgement procedures and
   messages are as defined in Sections 5.1.3 and 5.1.4.


5.2.2  End-to-End Switchover Request

   This message is generated by the source OXC receiving an indication
   of failure in a connection. It is sent to the Next OXC in the
   protection path.

   The format of this message is as follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x06   |   Length    |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Connection ID (Source ID)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Connection ID (Connection Index)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Status                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The Status field is set to 0x01 if the end OXC is able to switchover
   to the protection path. Otherwise, it is set to 0x00.

   This message is transmitted periodically by the end OXC, as
   controlled by the configurable parameter, End-to-End Retransmission
   Timer. The default value of this parameter is 90ms. The OXC stops
   transmitting this message under the following conditions:




                          Expires on 2/20/02                   Page 17

               draft-bala-restoration-signaling-01.txt


   o    A corresponding End-to-End Switchover Response message is
        received;

   o    The End-to-End Switchover Timer expires; or

   o    The connection is explicitly de-provisioned.

   Each intermediate OXC receiving such a message does the following.
   The OXC looks up the table entry corresponding to the Connection ID:

   o    If there is no table entry, the received message is silently
        discarded.

   o    Otherwise, if the Protection Type for the connection is Shared
        then the Source Address in the IP header of the message is
        compared with the Previous OXC field:

        -       If there is no match then the received message is
                silently discarded.


        -       Otherwise,

                o       The value of the received Status field is
                        checked. If it is 0x00 then the received
                        message is sent in an IP packet to the Next
                        OXC, with Source Address set to the address of
                        the sending OXC and Destination Address set to
                        Next OXC.

                o       If the received Status field is 0x01 then it is
                        checked if the protection path for the
                        connection can be activated. If so, the message
                        is passed on to the Next OXC as described
                        above.

                o       If the received Status field is 0x01, but the
                        protection path for the connection cannot be
                        activated then the message is passed on to the
                        Next OXC as described above, with the Status
                        field set to 0x00.


5.2.3 End-to-End Switchover Response

   This message is sent by the destination OXC receiving an End-to-End
   Switchover Request message. It is sent to the previous OXC in the
   protection path.

   The format of this message is as follows:




                          Expires on 2/20/02                   Page 18

               draft-bala-restoration-signaling-01.txt


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=0x09   |   Length    |      Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Connection ID (Source ID)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Connection ID (Connection Index)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Status                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   This message is transmitted in response to each End-to-End
   Switchover Request message received. If the Status field was set to
   0x00 in the Request message, it is set to 0x00 in this message also.
   Otherwise, the Status field is set to 0x01 or 0x00 depending on
   whether the destination OXC is able to switchover to the protection
   path or not, respectively.

   Each intermediate OXC receiving such a message does the following.
   The OXC looks up the table entry corresponding to the Connection ID:

   o    If there is no table entry, the received message is silently
        discarded.

   o    Otherwise, if the Protection Type for the connection is
        "shared" then the Source Address in the IP header of the
        message is compared with the Next OXC field:

        -       If there is no match then the received message is
                silently discarded.
        -       Otherwise,


                o       The value of the received Status field is
                        checked. If it is 0x00 then the received
                        message is sent in an IP packet to the Previous
                        OXC, with Source Address set to the address of
                        the sending OXC and Destination Address set to
                        Previous OXC. The protection path is not
                        activated in this case.

                o       If the received Status field is 0x01 then the
                        protection path for the connection is activated
                        and the message is passed on to the Previous
                        OXC as described above.








                          Expires on 2/20/02                   Page 19

               draft-bala-restoration-signaling-01.txt


6.  Discussion

6.1  Relationship between Local and End-to-End Protection Procedures

   In general, local protection may be attempted before invoking end-
   to-end protection. The exception to this is when end-to-end 1+1
   protection is used for a connection. In this case, it is better to
   directly invoke end-to-end protection since alternate path resources
   are already active for the connection.

   Thus, the general guideline that may be considered is to note the
   protection type of connections in intermediate OXCs during
   provisioning, and invoke local span protection only for working
   links carrying connections that are not 1+1 protected end-to-end.
   This implies that when a working link carries more than one
   connection, all the connections must have the same end-to-end
   protection type. The provisioning process must ensure this. If this
   is not possible then local span protection may be invoked for
   working links that have at least one connection that is not end-to-
   end 1+1 protected.

6.2   Connection Priorities During Protection

   The local protection procedure described in this draft switches all
   the connections on a failed working link onto a protection link. The
   advantage of this approach is that the signaling between OXCs is at
   the level of links and not at the level of connections. This is
   beneficial if a link could potentially carry a number of
   connections. On the other hand, it limits flexibility, since a
   working link must carry connections of similar priority. Otherwise,
   it is not possible to ensure that higher priority connections are
   favored over lower priority connections when a failure event affects
   more than one working link and there are fewer protection links than
   the number of failed working links.

   Also, under the above failure scenario, a decision must be made as
   to which working links (and therefore connections) are chosen to be
   protected and in what priority order. In general, an OXC might
   detect failures sequentially, i.e., all failed working links may not
   be detected simultaneously, but only sequentially. In this case, as
   per the proposed signaling procedures, connections on a working link
   may be switched over to a given protection link, but another failure
   (of a working link carrying higher priority connections) may be
   detected soon afterwards. In this case, the new connections may bump
   the ones previously switched over the protection link.

   In the case of end-to-end shared protection, priorities may be
   implemented for allocating shared link resources under multiple
   failure scenarios. Note that shared protection works under the
   assumption that the primary path of connections whose backups share
   resources are SRLG-disjoint [1]. Under single-failure scenarios,
   this would ensure that exactly one connection will "claim" the
   allocated (shared) resources. But under multiple failure scenarios,

                          Expires on 2/20/02                   Page 20

               draft-bala-restoration-signaling-01.txt


   more than one connection can claim shared resources. If such
   resources are allocated to a lower priority connection, they may
   have to be reclaimed and allocated to a higher priority connection.
   Furthermore, the lower priority connection must be de-provisioned
   along the protection path (this can be done using the signaling
   mechanisms developed for provisioning, rather than restoration
   signaling). The proposed signaling mechanisms can support
   connection-priority based allocation of shared resources during
   restoration signaling (specifically, during the Switchover Response
   step).

   A way to simplify end-to-end shared protection is to allocate shared
   resources to connections of the same priority. This way, a
   connection will not be first allocated shared resources and then
   bumped from the protection path.


6.3  Multi-Domain Restoration

   When an end-to-end connection follows a long path through multiple
   routing or administrative domains, it may be required to consider an
   intermediate form of restoration, called "intra-domain end-to-end
   restoration". With this approach, a failure within a domain would
   result in end-to-end restoration between the connection ingress and
   egress points within the domain (perhaps after local span
   restoration is attempted). When this fails, or if a failure occurs
   in an inter-domain link, full end-to-end restoration will be
   attempted.

   This type of a structured approach for restoration is particularly
   useful in the near term when an optical internetwork may be
   constructed by interconnecting multi-vendor optical subnetworks [1].
   In this case, intra-domain restoration may be proprietary, with
   standard restoration signaling implemented between border OXCs. But
   this type of restoration also requires some hardware support at the
   border nodes.

6.4   Optical mesh restoration and MPLS-based recovery

     Over the past year or so, there has been considerable work on
     MPLS-based recovery under the auspices of the MPLS WG (see, for
     example, [3], [5], [6], [7], [8], [9], and [10]), with a framework
     document [4] being adopted as a WG document.

     The terminology outlined at the start of this document is also
     explained in the MPLS-recovery framework document [4], in the
     context of MPLS LSP-based recovery.

     The failure indication message of Section 4, is quite similar to
     the failure indication signal (FIS) defined in [5], and elaborated
     on in [9] and [10]. A difference between the schemes and message
     formats discussed in this document and those presented in [5],
     [9], and [10], is that these documents focus primarily on MPLS LSP

                          Expires on 2/20/02                   Page 21

               draft-bala-restoration-signaling-01.txt


     restoration. As such, the messages defined therein contain
     explicit label information for packet LSPs, which is not required
     in optical networks. Further, [5] does not specifically cover the
     case of the coordinated signaling required for local span
     protection and for M:N protection with pooled protection links,
     which are central to this proposal.

6.5  Implementation Considerations

   As described in this draft, restoration signaling does not require
   any central actions (such as admission control or centralized
   resource allocation) within an OXC for end-to-end protection. Local
   span protection may require the consideration of all available
   protection link resources at the master. But end-to-end protection,
   which is more difficult from a latency perspective, can be
   controlled by distributing multiple, independent protocol instances
   in an OXC such that each instance covers a subset of connections
   passing through an OXC. Such optimizations would depend on the
   architecture of the systems implementing the proposed protocol.

6.6  Summary of Proposed Messages and Timers

   The following messages were introduced in this draft:

   Message Type    Message Name

   0x01         Failure Indication
   0x02         Switchover Request
   0x03         Switchover Response
   0x04         End-to-End Failure Indication
   0x05         End-to-End Failure Acknowledge
   0x06         End-to-End Switchover Request
   0x07         End-to-End Switchover Response


   The following timers were introduced in this draft:


   Timer Name                    Default Value  Messages Governed

   Retransmission Timer                  30 ms       1, 2
   Failure Indication Timer              500 ms      1
   Switchover Timer                      500 ms      2
   End-to-End Retransmission Timer       90 ms       4, 6
   End-to-End Failure Indication Timer   1000 ms     4
   End-to-End Switchover Timer           1000 ms     6








                          Expires on 2/20/02                   Page 22

               draft-bala-restoration-signaling-01.txt


7.  Conclusion

   In this draft, a signaling mechanism for fast restoration in optical
   mesh networks was described. The proposed mechanism consists of a
   protocol running directly over IP. The proposed messages are short
   and the interaction amongst nodes as proposed is rather simple. This
   proposal deals with local span protection and end-to-end protection,
   1+1 and shared.

   It is likely that the structure of the proposed mechanism would
   allow restoration to be completed quickly. Clearly, extensive
   quantitative evaluation is needed before the responsiveness of the
   proposed mechanism can be established.

   The specification of finite state machines in intermediate and end
   nodes for different protection modes is left for future work.


References


   1. B. Rajagopalan, et al., "IP over Optical Networks: A Framework",
      draft-many-ip-optical-framework-02.txt.

   2. J. P. Lang, et al, ""Link Management Protocol", draft-ietf-mpls-
      lmp-01.txt.

   3. P. Ashwood-Smith, et al., "Generalized MPLS: Signaling Functional
      Specification," draft-ietf-mpls-generalized-signaling-01.txt.

   4. Makam, et al, "Framework for MPLS-based Recovery," draft-ietf-
      mpls-recovery-frmwrk-02.txt, February 2001.

   5. K. Owens et al, "A Path Protection/Restoration Mechanism for MPLS
      Networks," draft-chang-mpls-path-protection-02.txt, November 2000.

   6. Kini, S., et al, "Shared Backup Label Switched Path Restoration,"
      draft-kini-restoration-shared-backup-00.txt, November 2000.

   7. Hellstrand, F., and Andersson, L., "Extensions to CR-LDP and RSVP-
      TE for setup of pre-established recovery tunnels," draft-
      hellstrand-recovery-merge-01.txt, November 2000.

   8. D. Haskin, Krishnan, R., "A Method for Setting up an Alternative
      Label Switched Path to Handle Fast Reroute," draft-haskin-mpls-
      fast-reroute-05.txt, November, 2000.

   9. K. Owens et al, "Extensions to RSVP-TE for MPLS Path Protection,"
      draft-chang-mpls-rsvpte-path-protection-ext-01.txt, November 2000.

   10. K. Owens et al, "Extensions to CR-LDP for MPLS Path
     Protection," draft-owens-mpls-crldp-path-protection-ext-01.txt,
     November 2000.

                          Expires on 2/20/02                   Page 23

               draft-bala-restoration-signaling-01.txt



Author Information


   Bala Rajagopalan, Debanjan Saha              Greg Bernstein
   Tellium, Inc.                                Ciena Corp.
   2 Crescent Place                             10480 Ridgeview Court
   Ocean Port, NJ 07757                         Cupertino, CA 94014
   Ph.: +1-732-923-4237, 4264                   Ph: +1-408 366 4713
   Email: {braja, dsaha}@tellium.com            Email: gregb@ciena.com

   Vishal Sharma
   Metanoia, Inc.
   335 Elan Village Lane, Unit 203
   San Jose, CA 95134-2539
   Ph: +1-408-943-1794
   Email: v.sharma@ieee.org





































                          Expires on 2/20/02                   Page 24