[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft                                  Bala Rajagopalan
draft-bala-protection-restoration-signaling-    Debanjan Saha
00.txt                                            Tellium, Inc.
Expires on: 5/14/2002                           G. Bernstein
                                                  Ciena Corp.
                                                Vishal Sharma
                                                  Metanoia, Inc.
                                                Ayan Banerjee
                                                John Drake
                                                Jonathan Lang
                                                  Calient Networks
                                                Jennifer Yates
                                                Guangzhi Li

   Signaling for Protection and 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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

1. Abstract

   Protection and restoration of switched connections under tight time
   constraints is a challenging problem in optical mesh networks. This
   draft describes different local and end-to-end protection modes for
   connections, and the message flow required for protection and
   restoration-related signaling.

                         Expires on 5/14/2002                   Page 1


2. Introduction

   Protection and restoration of switched connections under tight time
   constraints is a challenging problem in optical mesh networks. Such
   a network consists of optical or photonic cross-connects (referred
   to as "nodes") connected in a general topology [1]. Restoration
   typically involves the activation of an alternate (or "protection")
   path for a connection when a failure is encountered in the primary
   (or working) path. A path for a connection (working or protection)
   is characterized by an ingress port, an egress port, and a set of
   intermediate nodes and links through which the connection is routed.
   The working and protection paths are typically resource-disjoint
   (e.g., node or link disjoint) other than the ingress and egress
   ports which remain the same.

   A bi-directional link between neighboring nodes 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 segments between the source and destination nodes,
   traversing intermediate nodes.

   The following distinction is made between the terms "protection" and
   "restoration", even though these terms are often used
   interchangeably [2]. Protection is defined as the paradigm whereby a
   dedicated protection path is pre-established for a connection, and
   the connection is merely switched at the endpoints from the working
   to the protection path after a failure. The term restoration, on the
   other hand, is used to denote the paradigm whereby a protection path
   for a connection may be selected apriori, but its establishment
   occurs only after a failure in the working path. This distinction is
   subtle, and both protection and restoration require signaling.

   Protection can be "local span" or "end-to-end". Local span
   protection refers to the protection of the link (and hence
   connection segments routed over the link) between two neighboring
   switches. End-to-end protection refers to the protection of an
   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 or is not desired). 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),
   unless noted otherwise.

2.1 Local Span Protection

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

                          Expires on 8/22/01                    Page 2


        1+1 (unidirectional): A dedicated link j is pre-assigned to
        protect working link i. Connection traffic is simultaneously
        sent on both links and received independently by A and B from
        one of the functioning links, i or j. Thus, it is possible that
        nodes A and B may be receiving traffic from different links.

        1+1 (bi-directional): A dedicated 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 nodes 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:N: A dedicated link j between A and B is pre-assigned to
        protect a set of N 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 N links are concurrently affected by
        failures, the traffic on only one of the N links may be
        restored over link j.

        M:N (with pre-configured protection groups): A protection group
        of M+N links consists of a set of N links protected by a set of
        M other links, with M < N. (Link i must be one of the N links
        in a protection group, and link j is one of the M links). A
        failure in any of the N links results in traffic being switched
        to one of the (available) M 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 are pre-configured.
        Since M < N, it is possible that not all failed links in the
        set of N links may be protected from the same failure event.

        M:N (pooled protection links): Under this mode, a total of M
        links are assigned to protect a total of N other links between
        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 N links, and link j is one
        of the set of M links). This mode thus differs from the
        previous where there could be multiple hard-configured
        protection groups and working links in one group cannot be
        protected by protection links in another group. Furthermore,
        under this mode, the number of protection links need not be
        pre-configured and may vary depending on the demand from
        working traffic. Indeed, any available link can be used for
        protection purposes during a failure event. Thus, this is a
        more general and flexible protection mode compared to the
        previous. For administrative purposes, however, the value of M,
        N, and the specific links in the set of M protection links may
        be pre-determined. As before, since M < N, it is possible that
        not all failed links in the set of N links may be protected
        from the same failure event.

                          Expires on 8/22/01                    Page 3


   Since M:N (with pre-configured protection groups) and 1:N are
   special cases of M:N (pooled protection links), we focus on the
   signaling requirements for M:N protection with pooled protection

2.1 End-to-End Protection and Restoration

   Considering end-to-end protection, suppose a connection's primary
   path is from an ingress port in node A to an egress port in node B
   over a set of intermediate nodes. The following protection and
   restoration modes may be used:

        1+1 (unidirectional) protection: 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 nodes, A
        and B.

        1+1 (bi-directional) protection: A dedicated, resource-disjoint
        alternate path is pre-established to protect the connection.
        Connection traffic is simultaneously sent on both paths; under
        normal conditions, the traffic from the primary path is
        received by nodes 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

        Shared mesh restoration: An alternate path is pre-assigned to
        protect the connection, but the resources along the alternate
        path may be shared among multiple connections being protected
        (based on criteria described later). In this case, the
        resources are allocated in real-time for one of the protected
        connections whose primary path is affected by a failure. If
        more than one connection sharing a resource is concurrently
        affected by a failure, only one of them will be allocated  the
        shared resource.

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

   The aim of this draft is to define the message flows for M:N pooled
   local span protection, 1+1 (bi-directional)protection and shared
   mesh restoration. 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 [2].

                          Expires on 8/22/01                    Page 4


   Sections 3 and 4 describe local span and end-to-end protection
   protocols in detail. Section 5 describes certain administrative
   procedures related to restoration. Section 6 presents some
   discussion items and Section 7 presents the conclusions.

3. Local Span Protection

   Local span protection is described with respect to two neighboring
   nodes A and B. The scenario considered for local span protection
   (M:N with pooled protection links) 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 N (bi-directional) links carrying
        traffic subject to protection and a protection set of M (bi-
        directional) links. A protection link may have no traffic on
        it, or it may be carrying traffic that could be preempted.
        There is no a priori relationship between the two sets of
        links, but the value of M and N may be pre-configured. The
        specific links in the protection set MAY be pre-configured to
        be physically diverse to avoid the possibility that failure
        events affect a large proportion of protection 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 protection set, if
        such a link is available. Note that such a link might consist
        of more than one connection e.g., 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 protection 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
        protection 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 node is assumed to have an identifier, called the Node ID.
        Each node is also 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 [3]).

   o    When traffic must be diverted from a failed link in the working
        set to a protection link, the decision as to which protection
        link is chosen is always made by one of the nodes, A or B. As
        per this draft, the node with the numerically higher Node ID is
        considered the "master" and it is required to both apply any
        policies and select specific protection links to divert working
        traffic. The other node is considered the "slave". The
        determination of the master and the slave may be based on

                          Expires on 8/22/01                    Page 5


        configured information, or as a 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 protection 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 protection 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 protection
        link, it indicates this to the slave and requests the
        switchover of the traffic. Prior to this, if the protection
        link is carrying traffic that could be preempted, 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
        protection link).

   4.   The slave sends an acknowledgement to the master. Prior to
        this, if the selected protection link is carrying traffic that
        could be preempted, 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 protection link). It then starts
        sending the (failed) working link traffic on the selected
        protection link.

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

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

3.1  Identifiers

                          Expires on 8/22/01                    Page 6


   Node ID: An identifier that uniquely identifies each node in the

   Link ID: An identifier that uniquely identifies a bi-directional
   link at the sending and the receiving node.

   The messages are as follows. All these messages must be transmitted
   reliably from the message source to the message destination (master
   or slave).

3.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 number of links included in the message would depend on the
   number of failures detected within a window of time by the sending
   node. A node 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
   node. The master must convert this to the corresponding ID at its

3.3  Switchover Request Message

   This message is sent from the master to the slave (reliably) to
   indicate whether the traffic on the failed working link can be
   switched to a free link. If so, the ID of the free link must be

   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.

   A link being protected may carry multiple connections. Since the
   entire working link is switched to a protection link, it may be
   possible for the connections on the working link to be mapped to the
   protection link by the master and slave without coordination (e.g.,
   if the channel assignments (i.e., "labels") are the same on the
   working and protect links). Optionally, if it is necessary, the
   channel assignments (labels) may be explicitly coordinated between
   the master and the slave (e.g., when a smaller capacity link is
   protected by a larger capacity link). In this case, the Switchover
   Request message should carry the new label mappings selected by the

                          Expires on 8/22/01                    Page 7


   The master may not be able to find protection lines to accommodate
   all failed working links. Thus, if this message is generated in
   response to a Failure Indication message from the slave then the set
   of failed links in the message may be a sub-set of the links
   received in the Failure Indication message. Depending on time
   constraints, the master may switch the set of failed links in
   smaller batches. Thus, A failure event may result in the master
   sending more than one Switchover Request message to the same slave

3.4  Switchover Response Message

   This message is sent from the slave to the master (reliably) to
   indicate the completion (or failure) of switchover at the slave.

   In this message, the slave may indicate that it cannot switch over
   to the corresponding free link for some reason. The action to be
   taken by the master in this case 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).

3.5  Preventing Unintended Connections

   An unintended connection occurs when traffic from the wrong source
   is delivered to a receiver. These should be prevented during
   protection switching. This is a concern only when the protection
   link is being used to carry (unprotected) traffic that could be
   preempted. In this case, it must be ensured that the traffic being
   switched from the failed working link to the protection link is not
   delivered to the receiver of the traffic preempted. Thus, in the
   message flow described above, the master should disconnect (any)
   preempted traffic on the selected protection link before sending the
   Switchover Request. The slave should also disconnect preempted
   traffic before sending the Switchover Response. In addition, the
   slave should start receiving traffic for the protected connection
   from the protection link. Finally, the master should start sending
   protected traffic on the protection link upon receipt of the
   Switchover Response.

4.  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
   former is on a per-connection basis while the latter is on a per-
   link 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.

                          Expires on 8/22/01                    Page 8


   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 to the
   source of the connection. The messages are typically forwarded along
   the connection path, working or protection, where it is assumed that
   there is a control channel between each pair of intermediate nodes.
   If the optical network has routing intelligence, some of these
   messages can also be routed over other paths.

   There are two cases to be considered: signaling for bi-directional
   1+1 protection and for shared mesh restoration. The description
   below is in the context of an end-to-end connection between a source
   node A and a destination node B.

4.1  Bi-directional 1+1 Protection

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

   A node in the working path detects a failure event. Such a node must
   send a failure indication signal towards the source of the
   connection. This message may be forwarded along the working path, or
   routed over a different path if the network has general routing
   intelligence. Mechanisms provided by the lower layer may also be
   used for this, if available.

   The action when the source node is notified of a failure is as

   o    Start receiving from the protection path. At the same time,
        send a message to the destination node to enable switching at
        the destination.

   The action when the destination node receives the above message is
   as follows:

   o    Start receiving from the protection path. At the same time,
        send an acknowledgement to the source node.

   (These two messages may be forwarded along the protection path if no
   other routing intelligence is available in the network)

4.1.1  Identifiers

   Connection ID: A unique ID for each connection.

   Source ID: ID of the source (e.g., IP address).

   Destination ID: ID of the destination (e.g., IP address).

                          Expires on 8/22/01                    Page 9


4.1.2  Nodal Information

   Each node that is on the working or protection path of a connection
   must at least have knowledge of the connection identifier, the
   previous and next nodes in the connection path and the type of
   protection being afforded to the connection (i.e., 1+1 or shared).
   This is so that restoration-related messages may be forwarded
   properly. The optical network may also have additional routing
   intelligence. In this case, messages may be forwarded along paths
   different than the connection path.

   The nodal information may be assembled 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
   information must remain until the connection is explicitly de-

4.1.3  End-to-End Failure Indication Message

   This message is sent (reliably) by an intermediate node towards the
   source of a 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.

   Consider a node detecting a link failure. The node must determine
   the identities of all connections that are affected by the failure
   of the link, and send an end-to-end failure indication message to
   the source of each connection. Each intermediate node receiving such
   a message must determine the appropriate next node to forward the
   message such that the message would reach the connection source.
   Furthermore, if an intermediate node is itself generating a failure
   indication message, there should be a mechanism to suppress all but
   one source of failure indication messages. Finally, the failure
   indication message must be sent reliably from the node detecting the
   failure to the connection source. Reliability may be achieved, for
   example, by re-transmitting the message until an acknowledgement is

4.1.4  End-to-End Failure Acknowledge Message

   This message is sent by the source node in response to an End-to-End
   failure indication message. This message is sent to the originator
   of the failure indication message. The acknowledge message should be
   sent for each failure indication message received.

   Each intermediate node receiving the acknowledge message must
   forward it towards the destination of the message.

4.1.5  End-to-End Switchover Request Message

                          Expires on 8/22/01                   Page 10


   This message is generated by the source node receiving an indication
   of failure in a connection. It is sent to the connection
   destination, and it carries the Connection ID of the connection
   being restored. This message must indicate whether the source is
   able to switch over to the protection path or not. If the source is
   not able to switchover, the destination may not also switch over.

   The End-to-End Switchover message must be sent reliably from the
   source to the destination of the connection.

4.1.6  End-to-End Switchover Response Message

   This message is sent by the destination node receiving an End-to-End
   Switchover Request message towards the source of the connection.
   This message should indicate the Connection ID of the connection
   being switched over.

   This message must be transmitted in response to each End-to-End
   Switchover Request message received.

4.2  Shared Mesh Restoration

   Shared mesh restoration requires prior soft-reservation of capacity
   along the protection path [4]. Furthermore, after a failure event,
   the protection path must be explicitly activated. This requires
   actions at each intermediate node 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
   mesh restoration capacity may be claimed for more than one failed
   connection and the protection path can be activated only for one of
   them (at most).

   For implementing shared mesh restoration, the identifier and nodal
   information 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 node must also keep information needed to establish the data
   plane of the protection path. This information could be fine-
   grained, indicating 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 node and connection (The Generalized MPLS
   signaling draft describes different type of switches [5]).

   On the other hand, this information could be coarse-grained,

   { Connection ID, <Incoming TE link>, <Outgoing TE link> }

                          Expires on 8/22/01                   Page 11


   In this case, a specific component link and channel on the TE link
   is allocated only when the protection path is activated. While the
   coarser specification allows some flexibility in selection of the
   precise resource to activate, it also brings in more complexity in
   decision making and signaling during the time-critical restoration
   phase. Furthermore, the procedures for the assignment of bandwidth
   to protection paths must take into account the total resources in a
   TE link so that single-failure survivability requirements are

4.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.

4.2.2  End-to-End Switchover Request

   This message is generated by the source node receiving an indication
   of failure in a connection. It is sent to the connection destination
   along the protection path, and it carries the Connection ID of the
   connection being restored. This message must allow intermediate
   nodes to record whether they are able to activate the (shared)
   protection path. If any intermediate node is not able to establish
   cross-connects for the protection path then it is desirable that no
   other node in the path establishes cross-connects for the path. This
   would allow shared mesh restoration paths to be efficiently
   utilized. This requirement implies that switchover to the protection
   path occurs in two phases: in the forward phases, the Switchover
   Request message indicates the switching over action to intermediate
   nodes in the protection path and collects information as to their
   ability to switch over. In the reverse phase, the actual switchover
   occurs if all nodes in the path indicate their ability to switch

   The End-to-End Switchover message must be sent reliably from the
   source to the destination of the connection along the protection

4.2.3 End-to-End Switchover Response

   This message is sent by the destination node receiving an End-to-End
   Switchover Request message towards the source of the connection,
   along the protection path. This message should indicate the id of
   the connection being switched over, and whether all intermediate
   nodes have agreed to switch over  (as determined in the forward
   phase using the Switchover Request message).

   This message must be transmitted in response to each End-to-End
   Switchover Request message received.

5. Reversion and other Administrative Procedures

                          Expires on 8/22/01                   Page 12


   Reversion refers to the process of moving a connection back to the
   original working path from its protection path after the former is
   restored after a failure. Reversion applies both to local span and
   end-to-end path protected connections. Reversion is desired for the
   following reasons. First, the routing of the protection path often
   may not be as efficient as the routing of the working path.  Second,
   moving a connection to its working path allows the protection
   resources to be used to protect other connections.

   Reversion implies that a working path remains allocated to the
   connection that was originally routed over it even after a failure.
   It is important to have mechanisms that allow reversion to be
   performed without disrupting service to the customer. This can be
   achieved if reversion is implemented using a "bridge-and-switch"
   approach (often referred to as make-before-break).

   The basic steps involved in bridge-and-switch are:

   1.  The source node commences the process by "bridging" the signal
       onto both the working and the protection paths (or links in the
       case of span protection).
   2.  Once the bridging process is complete, the source node sends a
       Bridge and Switch Request message to the destination, identifying
       the connection and other information necessary to perform
       reversion. Upon receipt of this message, the destination selects
       the signal from the working path. At the same time, it bridges the
       transmitted signal onto both the working and protection paths.
   3.  The destination then sends a Bridge and Switch Response message to
       the source confirming the completion of the operation.
   4.  When the source receives this message, it switches to receive from
       the working path, and stops transmitting traffic on the protection
       path. The source then sends a Bridge and Switch Completed message
       to the destination confirming that the connection has been
   5.  Upon receipt of this message, the destination stops transmitting
       along the protection path and de-activates the connection along
       this path. The de-activation procedure should remove the cross-
       connections along the protection path (and frees the resources to
       be used for restoring other failures.

   Administrative procedures other than reversion include the ability
   to force a switchover (from working to protect or vice versa), and
   locking out switchover, i.e., preventing a connection from moving
   from working to protect or vice versa administratively. These
   administrative conditions have to be supported by signaling.

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

                          Expires on 8/22/01                   Page 13


   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 nodes 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 nodes 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, a node 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 mesh restoration, priorities may be
   implemented for allocating shared link resources under multiple
   failure scenarios. Note that shared mesh restoration 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) resource. But under multiple failure scenarios,
   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

                          Expires on 8/22/01                   Page 14


   connection-priority based allocation of shared resources during
   restoration signaling (specifically, during the Switchover Response

   A way to simplify end-to-end shared mesh restoration 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  Routing Aspects

   To compute end-to-end protection paths, it is necessary to know
   which network resources can be used. For end-to-end 1+1 protection,
   any free resource in the network can be used. In this regard, the
   computation of the working and the protection paths is similar. For
   shared mesh restoration, however, it is necessary to know the
   availability of shareable as well as free resources. Generally,
   protection paths may share resources if the corresponding working
   paths will not be affected by the same failure. Thus, to determine
   shareable resources for a given protection path optimally, it is
   necessary to know full information about other working paths.
   Maintaining this sort of information may be suitable in a
   centralized routing implementation, but it may be not be scaleable
   under distributed routing. Under distributed routing, heuristics are
   often used to provision shared protection paths [12]. The specific
   routing information to be propagated and the signaling for the
   provisioning of shared protection paths are topics to be dealt with
   in separate drafts.

6.4  Multi-Domain Restoration

   When an end-to-end connection follows a 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 could be
   attempted (inter-domain links could also be subject to local span

   This type of a structured approach for restoration is particularly
   useful in the near term when an optical network 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 nodes. But this
   type of restoration also requires some hardware support at the
   border nodes.

6.5 Optical mesh restoration and MPLS-based recovery

                          Expires on 8/22/01                   Page 15


     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, [6-11]), with a framework document [6] being adopted as a
     WG document.

     The terminology outlined at the start of this document is also
     explained in the MPLS-recovery framework document [6], 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 [7], and elaborated
     on in [10] and [11]. A difference between the schemes and message
     formats discussed in this document and those presented in [7],
     [10], and [11], is that these documents focus primarily on MPLS
     LSP restoration. As such, the messages defined therein contain
     explicit label information for packet LSPs, which is not required
     in optical networks. Further, [7] 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.6  Implementation Considerations

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

7.  Conclusion

   In this draft, the signaling message flows for protection and
   restoration in optical mesh networks was described. The types of
   protection modes considered were local span protection and end-to-
   end protection, 1+1 and shared. Specific protocol realization of the
   message flows will be described in other drafts.

8. References

   1. B. Rajagopalan, et al., "IP over Optical Networks: A Framework",
      draft-ietf-ipo -framework-00.txt.

   2. W.S Lai, et al., "Network Hierarchy and Multilayer Survivability,"
      Internet Draft, draft-team-tewg-restore-hierarchy-00.txt, July,

                          Expires on 8/22/01                   Page 16


   3. J. P. Lang, et al, "Link Management Protocol", draft-ietf-mpls-

   4. G. Li, et. al., "RSVP-TE Extensions For Shared-Mesh Restoration in
      Transport Networks," draft--li-shared-mesh-restoration-00.txt.

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

   6. Makam, et al, "Framework for MPLS-based Recovery," draft-ietf-

   7. K. Owens et al, "A Path Protection/Restoration Mechanism for MPLS
      Networks," draft-chang-mpls-path-protection-03.txt.

   8. Kini, S., et al, "Shared Backup Label Switched Path Restoration,"

   9. Hellstrand, F., and Andersson, L., "Extensions to CR-LDP and RSVP-
      TE for setup of pre-established recovery tunnels," draft-

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

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

   12. S. Sengupta and R. Ramamurthy, "Capacity Efficient Distributed
       Routing of Mesh-Restored Lightpaths in Optical Networks," Proc.
       IEEE Globecom 2001, November, 2001.

                          Expires on 8/22/01                   Page 17


9. Author Information

   Bala Rajagopalan                       Greg Bernstein
   Debanjan Saha                          Ciena Corp.
     Tellium, Inc.                        10480 Ridgeview Ct.
     2 Crescent Pl.                       Cupertino, CA 94014
     Ocean Port, NJ 07757                 Email: Greg@ciena.com
     Email: {braja, dsaha}@tellium.com

   Vishal Sharma                          Ayan Banerjee
   Metanoia, Inc.                         John Drake
   305 Elan Village Lane, Unit 121        Jonathan Lang
   San Jose, CA 95134                     Calient Networks
   Email: V.Sharma@ieee.org               5853 Rue Ferrari
                                          San Jose, CA 95138
                                          Email: {abanerjee, Jdrake,

   Jennifer Yates
   Guangzhi Li
   180 Park Ave.
   Florham Park, NJ 07932
   Email: {jyates, gli}@research.att.com

                          Expires on 8/22/01                   Page 18

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/