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

Versions: 00

Network Working Group                      Jonathan P. Lang (Chromisys)
Internet Draft                                Krishna Mitra (Chromisys)
Expiration Date: September 2000                  John Drake (Chromisys)



               Extensions to RSVP for optical networking

                    draft-lang-mpls-rsvp-oxc-00.txt



1. Status of this Memo

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

   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.

2. Abstract

   Dynamically provisionable optical crossconnects (OXCs) will play an
   active role in future optical networks and the MPL(ambda)S control
   plane will be used to establish, teardown, and reroute optical
   trails through the network.  This document specifies extensions to
   RSVP to address some of the unique requirements of such optical
   trails.  Specifically, we propose extensions to RSVP that allow an
   upstream node to make a Label suggestion to a downstream node when
   establishing an optical trail and allow both directions of a bi-
   directional optical trail to be established simultaneously.  A new
   message type is also defined so that an RSVP node can notify
   (possibly non-adjacent) RSVP nodes when network failures occur,
   without affecting the RSVP states of intermediate RSVP nodes.
   Finally, we propose a modification to allow bundle messages to be
   sent to non-adjacent RSVP nodes.






Lang/Mitra/Drake                                              [Page 1]


Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000

3. Conventions used in this document

   In this document, we follow the naming convention of [2] and use OXC
   to refer to all categories of optical crossconnects, irrespective of
   the internal switching fabric.  We use the term source node to refer
   to an RSVP node that initiates the optical trail establishment and
   the term destination node to refer to the RSVP node that terminates
   the trail at the other end of the network.  Furthermore, we call the
   message path from the source node to the destination node the
   downstream direction and the reverse path from the destination node
   back to the source node the upstream direction.  Note that for bi-
   directional connections our terminology is such that there is only
   one source node and one destination node.

4. Introduction

   Future optical networks will consist of label switched routers
   (LSRs) and optical crossconnects (OXCs) that internetwork using the
   MPL(ambda)S control plane.  Support for provisioning and restoration
   of end-to-end optical trails within this type of network imposes new
   requirements on the signaling protocols.  Specifically, optical
   trails will require small setup latency, support for bi-directional
   trails, and rapid restoration of trails in case of network failures.
   This document builds on work already done for traffic engineering in
   MPLS and proposes solutions for these requirements.

   The modifications proposed in this document enhance the extensions
   of RSVP-TE [3] to support the following functions:
     1.   Reduction of trail establishment latency by allowing
          resources to be configured in the downstream direction.
     2.   Establishment of bi-directional trails as a single process
          instead of establishing two uni-directional trails, one in
          each direction, each being a separate process.  Normally,
          both directions of a bi-directional trail have the same
          traffic engineering requirements and need to be routed over
          the same physical route.  As a result, they cannot be treated
          as two separate trail requests.
     3.   Fast failure notification to a node responsible for trail
          restoration can be achieved so that restoration techniques
          can be quickly initiated.  For example, for end-to-end path
          restoration, the source is responsible for rerouting failed
          trails, and must be notified when the trail's resources are
          involved in a failure.

   The organization of the remainder of this document is as follows.
   In Section 5, we propose a Label suggestion to reduce the trail
   establishment latency.  In Section 6, we present modifications to
   RSVP so that both directions of a bi-directional trails can be
   provisioned simultaneously.  In Section 7, we introduce a new Notify
   message that is to notify nodes when failures occur in the network.
   Finally, in Section 8, we discuss a modification to the bundle
   message [3] to allow transmission between non-adjacent nodes.



Lang/Mitra/Drake                                              [Page 2]


Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000

   5. Label suggestion

   Currently in RSVP, the Label object for an optical trail is returned
   in the Resv message.  A unique feature of OXCs is that selecting a
   (fiber, lambda) Label (see [4]) for a trail requires configuring the
   OXC so that an input is switched to an output, and all data that
   arrives over the input must go to the same output.  This is
   different from traditional LSRs where multiple flows from the same
   input maybe be assigned different Labels and subsequently switched
   to different outputs.  A consequence of this is that when an OXC is
   initially configured, Labels can be assigned to each input and
   output and protocols (such as LMP [5]) can be used to exchange Label
   mappings between adjacent nodes.

   A consequence of the inherent receiver-oriented nature of RSVP is
   that the internal configuration of an OXC in the downstream
   direction cannot be initiated until it receives the Resv message
   from the downstream node.  The ability to begin configuring an OXC
   before receiving a Label object in the Resv message can provide a
   significant reduction in the setup latency, especially in OXCs with
   non-negligible configuration time.

   To accomplish this, we propose that an upstream OXC suggest a
   (fiber, lambda) Label for the downstream node to use by including
   the suggested Label object in the Label Request object [3] of the
   Path message.  The Label object will contain the downstream nodeƆs
   Label for the bearer channel, which can be obtained through the Link
   Management Protocol (LMP) [5].  This will allow the upstream OXC to
   begin its internal configuration before receiving the Resv message
   from the downstream node.  If, however, the downstream node ignores
   the suggested Label and passes a different Label upstream, the
   upstream OXC must reconfigure itself so that it uses the label
   specified by the downstream node.


5.1. Label Request

   The LABEL_REQUEST object format is shown below, where we have
   defined a new C_Type for a suggested Label.


   Class = 19, C_Type = 5 (suggested label)

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Link Media Type         |            L3PID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Label Object                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Link Media Type:
   The Link Media Type is the two-octet media type values in IS-IS/OSPF
   Link Media Type TLV defined in [4].



Lang/Mitra/Drake                                              [Page 3]


Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000

   L3PID:
   The L3PID is an identifier of the layer 3 protocol using this path.
   Standard Ethertype values are used.

   Label Object:
   The Label object is the suggested Label for the downstream node.



6. Bidirectional Optical Paths

   In future optical networks, it may be desirable to establish bi-
   directional optical paths across the network.  Using RSVP-TE [3],
   this requires establishing two unidirectional paths: an initial path
   from the source to the destination and a subsequent path from the
   destination back to the source.  This approach has two
   disadvantages: the latency to establish the bi-directional path
   requires three source/destination transit times, and the time window
   between reserving the resources in the downstream direction and
   reserving them in the upstream direction may be large (as much as
   two times the source/destination transit time), decreasing the
   probability of successfully establishing the overall bi-directional
   path.

   To address the disadvantages of establishing bi-directional paths
   using current techniques in RSVP, we propose that a Label object is
   added to the Path message in the downstream direction.  In this way,
   the upstream direction of the bi-directional path is established on
   the first pass from the source to the destination, reducing the
   latency of the reservation process.  Furthermore, if suggested
   Labels are used for the downstream direction of the bi-directional
   path (see Section 5), then the time between reserving resources in
   the upstream and downstream directions can be eliminated, increasing
   the overall probability of success for the bi-directional path.

   The format of the Path message is as follows (where we assume the
   extensions of [3] are also implemented):

   <Path Message> ::= <Common Header> [ <INTEGRITY>] <SESSION>
                      <RSVP_HOP> <TIME_VALUES> [<EXPLICIT_ROUTE>]
                      [<LABEL>] <LABEL_REQUEST> [<SESSION_ATTRIBUTE>]
                      [<POLICY_DATA> ...] [<sender descriptor>]

   <sender descriptor> ::= <SENDER_TEMPLATE> [<SENDER_TSPEC>]
                      [<ADSPEC>] [<RECORD_ROUTE>]

   Note that for bi-directional trails, if a Label suggestion is also
   used, there will be two Labels in the Path message: the upstream
   Label in the Label object and the suggested Label in the
   Label_Request object.





Lang/Mitra/Drake                                              [Page 4]


Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000

6.1. Contention Resolution

   It is possible that a pair of uni-directional bearer channels (one
   in each direction) is routed together through the fiber optic
   infrastructure and that it is desirable to allocate a bi-directional
   trail to the pair.   (This would be known through local
   configuration at a given node.)  In this situation, it is possible
   to get a collision between two bi-directional path requests
   traveling in opposite directions between two adjacent nodes.  For
   example, this could occur if each node selects for its upstream
   direction a unidirectional bearer channel from the same pair.

   To address this situation, we propose that the node with the higher
   IP address wins the contention.  The node with the higher IP address
   will send a PATH_ERROR message to the adjacent node.  To ensure
   proper interpretation of the error, a new Error Code is defined
   (Error Code 25) to indicate that the resources could not be obtained
   due to a collision.  This message is intended for the adjacent node
   only, and should not be propagated further.  When the adjacent node
   receives the PATH_ERROR message with Error Code 25, it will try to
   allocate a different (fiber, lambda) Label to the bi-directional
   path.  If at that point, no other resources are available, the
   adjacent node will send a new PATH_ERROR message upstream towards
   the source node, indicating that resources were not available for
   the bi-directional path.


7. Failure Notification

   A requirement of reliable optical networks is that reaction to
   network failures must be quick, and rerouting decisions must be made
   intelligently.  A critical functionality of networking protocols
   that satisfy this requirement is the ability to rapidly detect and
   isolate failures as well as to notify the nodes responsible for
   restoring the failed optical trails.  Failure detection should be
   handled at the layer closest to the failure, the optical layer, and
   a number of techniques are being developed to facilitate rapid
   failure detection.  Failure isolation requires coordination between
   adjacent nodes, and protocols such as the LMP [5] can be used to
   rapidly isolate network failures using a lightweight messaging
   scheme.  Failure notification involves exchanging information
   between nodes that may or may not be adjacent, and signaling
   protocols should be used to exchange the information.  It should be
   clear that the methods used to detect and isolate network failures
   can be independent of the signaling protocol that is used to notify
   nodes of failed optical trails, and we will not consider failure
   detection/isolation techniques further in this document.

   As part of failure notification, a node passing transit trails
   (i.e., trails that neither originate nor terminate at that node)
   should be able to notify the nodes responsible for restoring the
   trails when failures occur (e.g., the source node needs to be
   notified if end-to-end path restoration is used), without
   intermediate nodes processing the messages or modifying the state of

Lang/Mitra/Drake                                              [Page 5]


Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000

   the affected trails.  This is important because restoration
   procedures may reuse segments of the original trail in a "make-
   before-break" fashion.  As part of the notification process, the
   affected trail and the failed resource must be identified in the
   message.

   We propose a new RSVP message, called the Notify message, which can
   be used to notify (possibly non-adjacent) RSVP nodes when failures
   occur.  The Notify message will be transmitted with the router alert
   option turned off so that intermediate nodes will not process or
   modify the message, but only perform standard IP forwarding of the
   message.

7.1. Notify message

   The Notify message is sent to the unicast address of an RSVP host.
   Notify messages do not modify the state of any node through which
   they pass and are only reported to the addressed RSVP host.

   <Notify message> ::= <Common Header> <SESSION> <ERROR_SPEC>
                        [<sender descriptor>]

   <sender descriptor> ::=  <SENDER_TEMPLATE> [<SENDER_TSPEC>]
                            [<ADSPEC>] [<RECORD ROUTE]>

   The ERROR_SPEC object specifies the error and includes the IP
   address of either the node that detected the error or the link that
   has failed.

8. Bundle message modification

   A recent Internet draft [3] proposed an extension to RSVP to allow
   the use of bundle messages to reduce the overall message-handling
   load.  An RSVP bundle message consists of a bundle header followed
   by a body consisting of a variable number of standard RSVP messages.
   Support for the bundle message is optional, and currently, bundle
   messages can only be sent to adjacent RSVP nodes.

   Future optical networks will require high reliability, which can be
   ensured by using fast protection and restoration techniques.  These
   techniques may be applied at the local level (e.g., span
   protection/restoration) and/or at the path level (e.g., path
   protection/restoration) and may require rerouting multiple optical
   paths simultaneously.  To enable fast protection/restoration
   techniques, an RSVP node may need to send multiple simultaneous
   messages to a nonadjacent RSVP node.  For example, an intermediate
   node may need to send multiple Notify messages (see Section 7.1) to
   a particular source RSVP node if it detects a failure affecting
   multiple trails with that node as the source.

   In order to effectively restore the network to a stable state, nodes
   that are running restoration algorithms should consider as many
   failed trails as possible before making restoration decisions.  To
   improve performance and ensure that the nodes are provided with as

Lang/Mitra/Drake                                              [Page 6]


Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000

   many of the affected paths as possible, it is useful to include the
   entire set of Notify messages in a single bundle message and send it
   to the responsible RSVP node directly, without message processing by
   the intermediate RSVP nodes.  This can be accomplished by addressing
   the bundle message to the source RSVP node and turning off the
   router alert option in the IP header.

   Intermediate RSVP nodes should perform standard IP forwarding of
   this message (i.e., they should not process the message) and must
   not alter its contents.  The source RSVP node must disable the RSVP
   neighbor check, which would normally cause it to discard the
   message.

   The source RSVP node will send an RSVP MESSAGE ACK (see [6]),
   containing the message IDs of all of the messages in the bundle
   message, addressed to the node that sent it the bundle message.
   Intermediate RSVP nodes should perform standard IP forwarding of
   this message (i.e., not process it) and must not alter its contents.

9. Security Considerations

   No new security issues are raised in this document.  See [7] for a
   general discussion of security issues for RSVP.

10. Referenc

   [1] Bradner, S., "The Internet Standards Process -- Revision 3," BCP
      9, RFC 2026, October 1996.
   [2] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi-
      Protocol Lambda Switching: Combining MPLS Traffic Engineering
      Control with Optical Crossconnects," Internet Draft, draft-
      awduche-mpls-te-optical-00.txt, October 1999.
   [3] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G.,
      Srinivasan, V., "Extensions to RSVP for LSP Tunnels," Internet
      Draft, draft-ietf-mpls-rsvp-lsp-tunnel-04.txt, September 1999.
   [4] Kompella, K., Rekhter, Y., Awduche, D. O., et al, "Extensions to
      IS-IS/OSPF and RSVP in support of MPL(ambda)S," Internet Draft,
      draft-kompella-mpls-optical.txt, February 2000.
   [5] Lang, J. P., Mitra, K., Drake, J., et al, "Link Management
      Protocol," Internet Draft, draft-lang-mpls-lmp-00.txt, March
      2000.
   [6] Berger, L., Gan, D.-H., Swallow, G., Pan, P., Tommasi, F., "RSVP
      Refresh Overhead Reduction Extensions," Internet Draft, draft-
      ietf-rsvp-refresh-reduct-02.txt, January 2000.
   [7] Braden, R., Zhang, L., Berson, S., et al, "Resource ReserVation
      Protocol -- Version 1 Functional Specification," RFC 2205,
      September 1997.

11. Author's Addresses

   Jonathan Lang                   Krishna Mitra
   Chromisys, Inc.                 Chromisys, Inc.
   421 Pine Avenue                 1012 Stewart Drive
   Santa Barbara, CA 93117         Sunnyvale, CA 94086

Lang/Mitra/Drake                                              [Page 7]


Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000

   Email: jplang@Chromisys.com     email: krishna@Chromisys.com

   John Drake
   Chromisys, Inc.
   1012 Stewart Drive
   Sunnyvale, CA 94086
   email: jdrake@Chromisys.com
















































Lang/Mitra/Drake                                              [Page 8]


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