Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

in Index   Prev   Next
in Index   None   Next  Group: IPO

RFC 3717

IP over Optical Networks: A Framework

Pages: 48
Part 2 of 2 – Pages 25 to 48
First   Prev   None

Top   ToC   Page 25   prevText
6.  IP-based Optical Control Plane Issues

   Provisioning and restoring lightpaths end-to-end between IP networks
   requires protocol and signaling support within optical sub-networks,
   and across the INNI and ENNI.  In this regard, a distinction is made
   between control procedures within an optical sub-network (Figure 1),
   between sub-networks, and between networks.  The general guideline
   followed in this framework is to separate these cases, and allow the
   possibility that different control procedures are followed inside
   different sub-networks, while a common set of procedures are followed
   across sub-networks and networks.

   The control plane procedures within a single vendor sub-network need
   not be defined since these can be proprietary.  Clearly, it is
   possible to follow the same control procedures inside a sub-network
   and across sub-networks.  But this is simply a recommendation within
   this framework document, rather than an imperative requirement. Thus,
   in the following, signaling and routing across sub-networks is
   considered first, followed by a discussion of similar issues across

6.1.  Addressing

   For interoperability across optical sub-networks using an IP-centric
   control plane, one of the fundamental issues is that of addressing.
   What entities should be identifiable from a signaling and routing
   point of view? How should they be addressed? This section presents
   some high level guidelines on this issue.
Top   ToC   Page 26
   Identifiable entities in optical networks include OXCs, optical
   links, optical channels and sub-channels, Shared Risk Link Groups
   (SRLGs), etc.  An issue here is how granular the identification
   should be as far as the establishment of optical trails are
   concerned.  The scheme for identification must accommodate the
   specification of the termination points in the optical network with
   adequate granularity when establishing optical trails.  For instance,
   an OXC could have many ports, each of which may in turn terminate
   many optical channels, each of which contain many sub-channels etc.
   It is perhaps not reasonable to assume that every sub-channel or
   channel termination, or even OXC ports could be assigned a unique IP
   address.  Also, the routing of an optical trail within the network
   does not depend on the precise termination point information, but
   rather only on the terminating OXC.  Thus, finer granularity
   identification of termination points is of relevance only to the
   terminating OXC and not to intermediate OXCs (of course, resource
   allocation at each intermediate point would depend on the granularity
   of resources requested).  This suggests an identification scheme
   whereby OXCs are identified by a unique IP address and a "selector"
   identifies further fine-grain information of relevance at an OXC.
   This, of course, does not preclude the identification of these
   termination points directly with IP addresses(with a null selector).
   The selector can be formatted to have adequate number of bits and a
   structure that expresses port, channel, sub-channel, etc,

   Within the optical network, the establishment of trail segments
   between adjacent OXCs require the identification of specific port,
   channel, sub-channel, etc.  With a GMPLS control plane, a label
   serves this function.  The structure of the label must be such that
   it can encode the required information [10].

   Another entity that must be identified is the SRLG [11].  An SRLG is
   an identifier assigned to a group of optical links that share a
   physical resource.  For instance, all optical channels routed over
   the same fiber could belong to the same SRLG.  Similarly, all fibers
   routed over a conduit could belong to the same SRLG.  The notable
   characteristic of SRLGs is that a given link could belong to more
   than   one SRLG, and two links belonging to a given SRLG may
   individually belong to two other SRLGs.  This is illustrated in
   Figure 6.  Here, the   links 1,2,3 and 4 may belong to SRLG 1, links
   1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3.
   Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8
   could belong to SRLG 4.  (In this example, the same SRLG, i.e., 1,
   contains links from two different adjacencies).
Top   ToC   Page 27
   While the classification of physical resources into SRLGs is a manual
   operation, the assignment of unique identifiers to these SRLGs
   within an optical network is essential to ensure correct SRLG-
   disjoint path computation for protection.  SRLGs could be identified
   with a flat identifier (e.g., 32 bit integer).

   Finally, optical links between adjacent OXCs may be bundled for
   advertisement into a link state protocol [12].  A bundled interface
   may be numbered or unnumbered.  In either case, the component links
   within the bundle must be identifiable.  In concert with SRLG
   identification, this information is necessary for correct path

6.2.  Neighbor Discovery

   Routing within the optical network relies on knowledge of network
   topology and resource availability.  This information may be gathered
   and used by a centralized system, or by a distributed link state
   routing protocol.  In either case, the first step towards network-
   wide link state determination is the discovery of the status of local
   links to all neighbors by each OXC.  Specifically, each OXC must
   determine the up/down status of each optical link, the bandwidth and
   other parameters of the link, and the identity of the remote end of
   the link (e.g., remote port number).  The last piece of information
   is used to specify an appropriate label when signaling for lightpath
   provisioning.  The determination of these parameters could be based
   on a combination of manual configuration and an automated protocol
   running between adjacent OXCs.  The characteristics of such a
   protocol would depend on the type of OXCs that are adjacent (e.g.,
   transparent or opaque).

   Neighbor discovery would typically require in-band communication on
   the bearer channels to determine local connectivity and link status.
   In the case of opaque OXCs with SONET termination, one instance of a
   neighbor discovery protocol (e.g., LMP [2]) would run on each OXC
   port, communicating with the corresponding protocol instance at the
   neighboring OXC.  The protocol would utilize the SONET overhead bytes
   to transmit the (configured) local attributes periodically to the
   neighbor.  Thus, two neighboring switches can automatically determine
   the identities of each other and the local connectivity, and also
   keep track of the up/down status of local links.  Neighbor discovery
   with transparent OXCs is described in [2].
Top   ToC   Page 28
   +--------------+          +------------+         +------------+
   |              +-1:OC48---+            +-5:OC192-+            |
   |              +-2:OC48---+            +-6:OC192-+            |
   |    OXC1      +-3:OC48---+     OXC2   +-7:OC48--+     OXC3   |
   |              +-4:OC192--+            +-8:OC48--+            |
   |              |          |            |  +------+            |
   +--------------+          +----+-+-----+  | +----+------+-----+
                                  | |        | |          |
                                  | |        | |          |
   +--------------+               | |        | |          |
   |              |          +----+-+-----+  | |   +------+-----+
   |              +----------+            +--+ |   |            |
   |     OXC4     +----------+            +----+   |            |
   |              +----------+    OXC5    +--------+     OXC6   |
   |              |          |            +--------+            |
   +--------------+          |            |        |            |
                             +------+-----+        +------+-----+

            Figure 6: Mesh Optical Network with SRLGs

6.3.  Topology Discovery

   Topology discovery is the procedure by which the topology and
   resource state of all the links in a network are determined.  This
   procedure may be done as part of a link state routing protocol (e.g.,
   OSPF, ISIS), or it can be done via the management plane (in the case
   of centralized path computation).  The implementation of a link state
   protocol within a network (i.e., across sub-network boundaries) means
   that the same protocol runs in OXCs in every sub-network.  If this
   assumption does not hold then interworking of routing between sub-
   networks is required.  This is similar to inter-network routing
   discussed in Section 6.7.  The focus in the following is therefore on
   standardized link state routing.

   In general, most of the link state routing functionality is
   maintained when applied to optical networks.  However, the
   representation of optical links, as well as some link parameters, are
   changed in this setting.  Specifically,

   o  The link state information may consist of link bundles [12]. Each
      link bundle is represented as an abstract link in the network
      topology.  Different bundling representations are possible.  For
      instance, the parameters of the abstract link may include the
      number, bandwidth and the type of optical links contained in the
      underlying link bundle [12].  Also, the SRLGs corresponding to
      each optical link in the bundle may be included as a parameter.
Top   ToC   Page 29
   o  The link state information should capture restoration-related
      parameters for optical links.  Specifically, with shared
      protection (Section 6.5), the link state updates must have
      information that allows the computation of shared protection

   o  A single routing adjacency could be maintained between neighbors
      which may have multiple optical links (or even multiple link
      bundles) between them.  This reduces the protocol messaging

   o  Since link availability information changes dynamically, a
      flexible policy for triggering link state updates based on
      availability thresholds may be implemented.  For instance, changes
      in availability of links of a given bandwidth (e.g., OC-48) may
      trigger updates only after the availability figure changes by a
      certain percentage.

   These concepts are relatively well-understood.  On the other hand,
   the resource representation models and the topology discovery process
   for hierarchical routing (e.g., OSPF with multiple areas) are areas
   that need further work.

6.4.  Protection and Restoration Models

   Automatic restoration of lightpaths is a service offered by optical
   networks.  There could be local and end-to-end mechanisms for
   restoration of lightpaths within a network (across the INNI).  Local
   mechanisms are used to select an alternate link (or network segment)
   between two OXCs across the INNI when a failure affects the primary
   link (or primary network segment) over which the (protected)
   lightpath is routed.  Local restoration does not affect the end-to-
   end route of the lightpath.  When local restoration is not possible
   (e.g., no alternate link is available between the adjacent OXCs in
   question), end-to-end restoration may be performed.  Under this
   scenario this, the affected lightpath may be rerouted over an
   alternate diverse path to circumvent failed resources.  For end-to-
   end restoration, alternate paths may be pre-computed to expedite the
   recovery time.  End to end restoration may also be mixed with local
   recovery in various ways depending on acceptable tradeoffs between
   utilization of network resources and recovery times.

   End-to-end protection may be based on two types of protection
   schemes; "1 + 1" protection or shared protection.  Under 1 + 1
   protection, a back-up path is established for the protected primary
   path along a physically diverse route.  Both paths are active and the
   failure along the primary path results in an immediate switch-over to
   the back-up path.  Under shared protection, back-up paths
Top   ToC   Page 30
   corresponding to physically diverse primary paths may share the same
   network resources.  When a failure affects a primary path, it is
   assumed that the same failure will not affect the other primary paths
   whose back-ups share resources.

   It is possible that different restoration schemes may be implemented
   within optical sub-networks.  It is therefore necessary to consider a
   two-level restoration mechanism.  Path failures within an optical
   sub-network could be handled using procedures specific to the sub-
   network.  If this fails, end-to-end restoration across sub-networks
   could be invoked.  The border OXC that is the ingress to a sub-
   network can act as the source for restoration procedures within a
   sub-network.  The signaling for invoking end-to-end restoration
   across the INNI is described in Section 6.6.3.  The computation of
   the back-up path for end-to-end restoration may be based on various
   criteria.  It is assumed that the back-up path is computed by the
   source OXC, and signaled using standard methods.

6.5.  Route Computation

   The computation of a primary route for a lightpath within an optical
   network is essentially a constraint-based routing problem.  The
   constraint is typically the bandwidth required for the lightpath,
   perhaps along with administrative and policy constraints.  The
   objective of path computation could be to minimize the total capacity
   required for routing lightpaths [13].

   Route computation with constraints may be accomplished using a number
   of algorithms [14].  When 1+1 protection is used, a back-up path that
   does not traverse on any link which is part of the same SRLG as links
   in the primary path must be computed.  Thus, it is essential that the
   SRLGs in the primary path be known during alternate path computation,
   along with the availability of resources in links that belong to
   other SRLGs.  This requirement has certain implications on optical
   link bundling.  Specifically, a bundled LSA must include adequate
   information such that a remote OXC can determine the resource
   availability under each SRLG that the bundled link refers to, and the
   relationship between links belonging to different SRLGs in the
   bundle.  For example, considering Figure 3, if links 1,2,3 and 4 are
   bundled together in an LSA, the bundled LSA must indicate that there
   are three SRLGs which are part of the bundle (i.e., 1, 2 and 3), and
   that links in SRLGs 2 and 3 are also part of SRLG 1.

   To encode the SRLG relationships in a link bundle LSA, only links
   which belong to exactly the same set of SRLGs must be bundled
   together.  With reference to Figure 3, for example, two bundles can
   be advertised for links between OXC1 and OXC2, with the following
Top   ToC   Page 31
   Bundle No.     SRLGs    Link Type   Number   Other Info
     1             1,2       OC-48       3          ---
     2             1,3       OC-192      1          ---

   Assuming that the above information is available for each bundle at
   every node, there are several approaches possible for path
   computation.  For instance,

   1. The primary path can be computed first, and the (exclusive or
      shared) back-up is computed next based on the SRLGs chosen for the
      primary path.  In this regard,

      o  The primary path computation procedure can output a series of
         bundles the path  is routed over.  Since a bundle is uniquely
         identified with a set of SRLGs, the alternate path can be
         computed right away based on this knowledge.  In this case, if
         the primary path set up does not succeed for lack of resources
         in a chosen bundle, the primary and backup paths must be

      o  It might be desirable to compute primary paths without choosing
         a specific bundle apriori.  That is, resource availability over
         all bundles between a node pair is taken into account rather
         than specific bundle information.  In this case, the primary
         path computation procedure would output a series of nodes the
         path traverses.  Each OXC in the path would have the freedom to
         choose the particular bundle to route that segment of the
         primary path.  This procedure would increase the chances of
         successfully setting up the primary path when link state
         information is not up to date everywhere.  But the specific
         bundle chosen, and hence the SRLGs in the primary path, must be
         captured during primary path set-up, for example, using the
         RSVP-TE Route Record Object [15].  This SRLG information is
         then used for computing the back-up path.  The back-up path may
         also be established specifying only which SRLGs to avoid in a
         given segment, rather than which bundles to use.  This would
         maximize the chances of establishing the back-up path.

   2. The primary path and the back-up path are computed together in one
      step, for example, using Suurbaale's algorithm [16].  In this
      case, the paths must be computed using specific bundle

   To summarize, it is essential to capture sufficient information in
   link bundle LSAs to accommodate different path computation procedures
   and to maximize the chances of successful path establishment.
   Depending on the path computation procedure used, the type of support
Top   ToC   Page 32
   needed during path establishment (e.g., the recording of link group
   or SRLG information during path establishment) may differ.

   When shared protection is used, the route computation algorithm must
   take into account the possibility of sharing links among multiple
   back-up paths.  Under shared protection, the back-up paths
   corresponding to SRLG-disjoint primary paths can be assigned the same
   links.  The assumption here is that since the primary paths are not
   routed over links that have the same SRLG, a given failure will
   affect only one of them.  Furthermore, it is assumed that multiple
   failure events affecting links belonging to more than one SRLG will
   not occur concurrently.  Unlike the case of 1+1 protection, the
   back-up paths are not established apriori.  Rather, a failure event
   triggers the establishment of a single back-up path corresponding to
   the affected primary path.

   The distributed implementation of route computation for shared back-
   up paths require knowledge about the routing of all primary and
   back-up paths at every node.  This raises scalability concerns.  For
   this reason, it may be practical to consider the centralization of
   the route computation algorithm in a route server that has complete
   knowledge of the link state and path routes.  Heuristics for fully
   distributed route computation without complete knowledge of path
   routes are to be determined.  Path computation for restoration is
   further described in [11].

6.6.  Signaling Issues

   Signaling within an optical network for lightpath provisioning is a
   relatively simple operation if a standard procedure is implemented
   within all sub-networks.  Otherwise, proprietary signaling may be
   implemented within sub-networks, but converted back to standard
   signaling across the INNI.  This is similar to signaling across the
   ENNI, as described in Section 6.7.  In the former case, signaling
   messages may carry strict explicit route information, while in the
   latter case the route information  should be loose, at the level of
   abstraction of sub-networks.  Once a route is determined for a
   lightpath, each OXC along the path must appropriately configure their
   cross-connects in a coordinated fashion.  This coordination is
   conceptually analogous to selecting incoming and outgoing labels in a
   label-switched environment.  Thus, protocols like RSVP-TE [9] may be
   adapted and used across the INNI for this purpose.  The adaptation of
   IP-based signaling protocols must take into account a number of
   peculiar attributes of optical networks.
Top   ToC   Page 33
6.6.1.  Bi-Directional Lightpath Establishment

   Lightpaths are typically bi-directional.  That is, the output port
   selected at an OXC for the forward direction is also the input port
   for the reverse direction of the path.  Since signaling for optical
   paths may be autonomously initiated by different nodes, it is
   possible   that two path set-up attempts are in progress at the same
   time.  Specifically, while setting up an optical path, an OXC A may
   select output port i which is connected to input port j of the "next"
   OXC B.  Concurrently, OXC B may select output port j for setting up a
   different optical path, where the "next" OXC is A.  This results in a
   "collision".  Similarly, when WDM functionality is built into OXCs, a
   collision occurs when adjacent OXCs choose directly connected output
   ports and the same wavelength for two different optical paths.  There
   are two ways to deal with such collisions. First, collisions may be
   detected and the involved paths may be torn down and re-established.
   Or, collisions may be avoided altogether.

6.6.2.  Failure Recovery

   The impact of transient partial failures must be minimized in an
   optical network.  Specifically, optical paths that are not directly
   affected by a failure must not be torn down due to the failure.  For
   example, the control processor in an OXC may fail, affecting
   signaling   and other internodal control communication.  Similarly,
   the control channel between OXCs may be affected temporarily by a
   failure.  These failure may not affect already established optical
   paths passing through the OXC fabric.  The detection of such failures
   by adjacent nodes, for example, through a keepalive mechanism between
   signaling peers, must not result in these optical paths being torn

   It is likely that when the above failures occur, a backup processor
   or a backup control channel will be activated.  The signaling
   protocol must be designed such that it is resilient to transient
   failures.  During failure recovery, it is desirable to recover local
   state at the concerned OXC with least disruption to existing optical

6.6.3.  Restoration

   Signaling for restoration has two distinct phases.  There is a
   reservation phase in which capacity for the protection path is
   established.  Then, there is an activation phase in which the back-up
   path is actually put in service.  The former phase typically is not
   subject to strict time constraints, while the latter is.
Top   ToC   Page 34
   Signaling to establish a "1+1" back-up path is relatively straight-
   forward.  This signaling is very similar to signaling used for
   establishing the primary path.  Signaling to establish a shared
   back-up path is a little bit different.  Here, each OXC must
   understand which back-up paths can share resources among themselves.
   The signaling message must itself indicate shared reservation.  The
   sharing rule is as described in Section 6.4: back-up paths
   corresponding to physically diverse primary paths may share the same
   network resources.  It may therefore be necessary for the signaling
   message to carry adequate information that allows an OXC to verify
   that appropriateness of having a set of back-up paths sharing

   Under both 1+1 and shared protection, the activation phase has two
   parts: propagation of failure information to the source OXC from the
   point of failure, and activation of the back-up path.  The signaling
   for these two phases must be very fast in order to realize response
   times in the order of tens of milliseconds.  When optical links are
   SONET-based, in-band signals may be used, resulting in expedited
   response.  With out-of-band control, it may be necessary to consider
   fast signaling over the control channel using very short IP packets
   and prioritized processing.  While it is possible to use RSVP or CR-
   LDP for activating protection paths, these protocols do not provide
   any means to give priority to restoration signaling as opposed to
   signaling for provisioning.  For instance, it is possible for a
   restoration-related RSVP message to be queued behind a number of
   provisioning messages thereby delaying restoration.  It may therefore
   be necessary to develop a notion of prioritization for restoration
   signaling and incorporate appropriate mechanisms into existing
   signaling protocols to achieve this.  Alternatively, a new signaling
   mechanism may be developed exclusively for activating protection
   paths during restoration.

6.7.  Optical Internetworking

   Within an optical internetwork, it must be possible to dynamically
   provision and restore lightpaths across optical networks.  Therefore:

   o  A standard scheme for uniquely identifying lightpath end-points in
      different networks is required.

   o  A protocol is required for determining reachability of end-points
      across networks.

   o  A standard signaling protocol is required for provisioning
      lightpaths across networks.
Top   ToC   Page 35
   o  A standard procedure is required for the restoration of lightpaths
      across networks.

   o  Support for policies that affect the flow of control information
      across networks will be required.

   The IP-centric control architecture for optical networks can be
   extended to satisfy the functional requirements of optical
   internetworking.  Routing and signaling interaction between optical
   networks can be standardized across the ENNI (Figure 1).  The
   functionality provided across ENNI is as follows.

6.7.1.  Neighbor Discovery

   Neighbor discovery procedure, as described in Section 6.2, can be
   used for this.  Indeed, a single protocol should be standardized for
   neighbor discovery within and across networks.

6.7.2.  Addressing and Routing Model

   The addressing mechanisms described in Section 6.1 can be used to
   identify OXCs, ports, channels and sub-channels in each network. It
   is essential that the OXC IP addresses are unique within the

   Provisioning an end-to-end lightpath across multiple networks
   involves the establishment of path segments in each network
   sequentially.  Thus, a path segment is established from the source
   OXC to a border OXC in the source network.  From this border OXC,
   signaling across NNI is used to establish a path segment to a border
   OXC in the next network.  Provisioning then continues in the next
   network and so on until the destination OXC is reached.  The usage of
   protocols like BGP for this purpose need to be explored.

6.7.3.  Restoration

   Local restoration across the ENNI is similar to that across INNI
   described in Section 6.6.3.  End-to-end restoration across networks
   is likely to be either of the 1+1 type, or segmented within each
   network, as described in Section 6.4.
Top   ToC   Page 36
7.  Other Issues

7.1.  WDM and TDM in the Same Network

   A practical assumption would be that if SONET (or some other TDM
   mechanism that is capable partitioning the bandwidth of a wavelength)
   is used, then TDM is leveraged as an additional method to
   differentiate between "flows".  In such cases, wavelengths and time
   intervals (sub-channels) within a wavelength become analogous to
   labels (as noted in [1]) which can be used to make switching
   decisions.  This would be somewhat akin to using VPI (e.g.,
   wavelength) and VCI (e.g., TDM sub-channel) in ATM networks.  More
   generally, this will be akin to label stacking and to LSP nesting
   within the context of Multi-Protocol Lambda Switching [1].  GMPLS
   signaling [4] supports this type of multiplexing.

7.2.  Wavelength Conversion

   Some form of wavelength conversion may exist at some switching
   elements.  This however may not be the case in some pure optical
   switching elements.  A switching element is essentially anything more
   sophisticated than a simple repeater, that is capable of switching
   and converting a wavelength Lambda(k) from an input port to a
   wavelength  Lambda(l) on an output port.  In this display, it is not
   necessarily the case that Lambda(k) = Lambda(l), nor is it
   necessarily the case that the data carried on Lambda(k) is switched
   through the device without being examined or modified.

   It is not necessary to have a wavelength converter at every switching
   element.  A number of studies have attempted to address the issue of
   the value of wavelength conversion in an optical network.  Such
   studies typically use the blocking probability (the probability that
   a lightpath cannot be established because the requisite wavelengths
   are not available) as a metric to adjudicate the effectiveness of
   wavelength conversion.  The IP over optical architecture must take
   into account hybrid networks with some OXCs capable of wavelength
   conversion and others incapable of this.  The GMPLS "label set"
   mechanism [4] supports the selection of the same label (i.e.,
   wavelength) across an NNI.

7.3.  Service Provider Peering Points

   There are proposed inter-network interconnect models which allow
   certain types of peering relationships to occur at the optical layer.
   This is consistent with the need to support optical layer services
   independent of higher layers payloads.  In the context of IP over
   optical networks, peering relationships between different trust
   domains will eventually have to occur at the IP layer, on IP routing
Top   ToC   Page 37
   elements, even though non-IP paths may exist between the peering

7.4.  Rate of Lightpath Set-Up

   Dynamic establishment of optical channel trails and lightpaths is
   quite desirable in IP over optical networks, especially when such
   instantiations are driven by a stable traffic engineering control
   system, or in response to authenticated and authorized requests from

   However, there are many proposals suggesting the use of dynamic,
   data-driven shortcut-lightpath setups in IP over optical networks.
   The arguments put forth in such proposals are quite reminiscent of
   similar discussions regarding ATM deployment in the core of IP
   networks.  Deployment of highly dynamic data driven shortcuts within
   core networks has not been widely adopted by carriers and ISPs for a
   number of reasons: possible CPU overhead in core network elements,
   complexity of proposed solutions, stability concerns, and lack of
   true economic drivers for this type of service.  This document
   assumes that this paradigm will not change and that highly dynamic,
   data-driven shortcut lightpath setups are for future investigation.
   Instead, the optical channel trails and lightpaths that are expected
   to be widely used at the initial phases in the evolution of IP over
   optical networks will include the following:

   o  Dynamic connections for control plane traffic and default path
      routed data traffic,

   o  Establishment and re-arrangement of arbitrary virtual topologies
      over rings and other physical layer topologies.

   o  Use of stable traffic engineering control systems to engineer
      lightpath connections to enhance network performance, either for
      explicit demand based QoS reasons or for load balancing).

   Other issues surrounding dynamic connection setup within the core
   center around  resource usage at the edge of the optical domain. One
   potential issue pertains to the number of flows that can be processed
   by an ingress or egress network element either because of aggregate
   bandwidth limitations or because of a limitation on the number of
   flows (e.g., lightpaths) that can be processed concurrently.

   Another possible short term reason for dynamic shortcut lightpath
   setup would be to quickly pre-provision paths based on some criteria
   (e.g., a corporate executive wants a high bandwidth reliable
   connection, etc.).  In this scenario, a set of paths can be pre-
   provisioned, but not actually instantiated until the customer
Top   ToC   Page 38
   initiates an authenticated and authorized setup requests, which is
   consistent with existing agreements between the provider and the
   customer.  In a sense, the provider may have already agreed to supply
   this service, but will only instantiate it by setting up a lightpath
   when the customer submits an explicit request.

7.5.  Distributed vs. Centralized Provisioning

   This document has mainly dealt with a distributed model for lightpath
   provisioning, in which all nodes maintain a synchronized topology
   database, and advertise topology state information to maintain and
   refresh the database.  A constraint-based routing entity in each node
   then uses the information in the topology database and other relevant
   details to compute appropriate paths through the optical domain.
   Once a path is computed, a signaling protocol (e.g., [9]) is used to
   instantiate the lightpath.

   Another provisioning model is to have a centralized server which has
   complete knowledge of the physical topology, the available
   wavelengths, and where applicable, relevant time domain information.

   A corresponding client will reside on each network element that can
   source or sink a lightpath.  The source client would query the server
   in order to set up a lightpath from the source to the destination.
   The server would then check to see if such a lightpath can be
   established based on prevailing conditions.  Furthermore, depending
   on the specifics of the model, the server may either setup the
   lightpath on behalf of the client or provide the necessary
   information to the client or to some other entity to allow the
   lightpath to be instantiated.

   Centralization aids in implementing complex capacity optimization
   schemes, and may be the near-term provisioning solution in optical
   networks with interconnected multi-vendor optical sub-networks.  In
   the long term, however, the distributed solution with centralization
   of some control procedures (e.g., traffic engineering) is likely to
   be the approach followed.

7.6.  Optical Networks with Additional Configurable Components

   Thus far, this memo has focused mainly on IP over optical networks
   where the cross-connect is the basic dynamically re-configurable
   device in the optical network.  Recently, as a consequence of
   technology evolution, various types of re-configurable optical
   components are now available, including tunable lasers, tunable
   filters, etc.  Under certain circumstances, it may be necessary to
Top   ToC   Page 39
   parameterize the characteristics of these components and advertise
   them  within the control plane.  This aspect is left for further

7.7.  Optical Networks with Limited Wavelength Conversion Capability

   At the time of the writing of this document, the majority of optical
   networks being deployed are "opaque".  In this context the term
   opaque means that each link is optically isolated by transponders
   doing optical-electrical-optical conversions.  Such conversions have
   the added benefit of permitting 3R regeneration.  The 3Rs refer to
   re-power, signal retiming and reshaping.  Unfortunately, this
   regeneration requires that the underlying optical equipment be aware
   of both the bit rate and frame format of the carried signal.  These
   transponders are quite expensive and their lack of transparency
   constrains the rapid introduction of new services [17].  Thus there
   are strong motivators to introduce "domains of transparency" wherein
   all-optical networking equipment would transport data unfettered by
   these drawbacks.

   Thus, the issue of IP over optical networking in all optical sub-
   networks, and sub-networks with limited wavelength conversion
   capability merits special attention.  In such networks, transmission
   impairments resulting from the peculiar characteristics of optical
   communications complicate the process of path selection.  These
   transmission impairments include loss, noise (due primarily to
   amplifier spontaneous emission -- ASE), dispersion (chromatic
   dispersion and polarization mode dispersion), cross-talk, and non-
   linear effects.  In such networks, the feasibility of a path between
   two nodes is no longer simply a function of topology and resource
   availability but will also depend on the accumulation of impairments
   along the path.  If the impairment accumulation is excessive, the
   optical signal to noise ratio (OSNR) and hence the electrical bit
   error rate (BER) at the destination node may exceed prescribed
   thresholds, making the resultant optical channel unusable for data
   communication.  The challenge in the development of IP-based control
   plane for optical networks is to abstract these peculiar
   characteristics of the optical layer [17] in a generic fashion, so
   that they can be used for path computation.

8.  Evolution Path for IP over Optical Architecture

   The architectural models described in Section 5 imply a certain
   degree of implementation complexity.  Specifically, the overlay model
   was described as the least complex for near term deployment and the
   peer model the most complex.  Nevertheless, each model has certain
   advantages and this raises the question as to the evolution path for
   IP over optical network architectures.
Top   ToC   Page 40
   The evolution approach recommended in this framework is the
   definition of capability sets that start with simpler functionality
   in the beginning and include more complex functionality later.  In
   this regard, it is realistic to expect that initial IP over optical
   deployments will be based on the domain services model (with overlay
   interconnection), with no routing exchange between the IP and optical
   domains.  Under this model, direct signaling between IP routers and
   optical networks is likely to be triggered by offline traffic
   engineering decisions.  The next step in the evolution of IP-optical
   interaction is the introduction of reachability information exchange
   between the two domains.  This would potentially allow lightpaths to
   be established as part of end-to-end LSP set-up.  The final phase is
   the support for the full peer model with more sophisticated routing
   interaction between IP and optical domains.

   Using a common signaling framework (based on GMPLS) from the
   beginning facilitates this type of evolution.  In this evolution, the
   signaling capability and semantics at the IP-optical boundary would
   become more sophisticated, but the basic structure of signaling would
   remain.  This would allow incremental developments as the
   interconnection model becomes more sophisticated, rather than
   complete re-development of signaling capabilities.

   From a routing point of view, the use of Network Management Systems
   (NMS) for static connection management is prevalent in legacy optical
   networks.  Going forward, it can be expected that connection routing
   using the control plane will be gradually introduced and integrated
   into operational infrastructures.  The introduction of routing
   capabilities can be expected to occur in a phased approach.

   It is likely that in the first phase, service providers will either
   upgrade existing local element management (EMS) software with
   additional control plane capabilities (and perhaps the hardware as
   well), or upgrade the NMS software in order to introduce some degree
   of automation within each optical subnetwork.  For this reason, it
   may be desirable to partition the network into subnetworks and
   introduce IGP interoperability within each subnetwork (i.e., at the
   I-NNI level), and employ either static or signaled interoperability
   between subnetworks.  Consequently, it can be envisioned that the
   first phase in the evolution towards network level control plane
   interoperability in IP over Optical networks will be organized around
   a system of optical subnetworks which are interconnected statically
   (or dynamically in a signaled configuration).  During this phase, an
   overlay interconnection model will be used between the optical
   network itself and external IP and MPLS routers (as described in
   Section 5.2.3).
Top   ToC   Page 41
   Progressing with this phased approach to IPO routing
   interoperabibility evolution, the next level of integration will be
   achieved when a single carrier provides dynamic optical routing
   interoperability between subnetworks and between domains.  In order
   to become completely independent of the network switching capability
   within subnetworks and across domains, routing information exchange
   may need to be enabled at the UNI level.  This would constitute a
   significant evolution: even if the routing instances are kept
   separate and independent, it would still be possible to dynamically
   exchange reachability and other types of routing information. Another
   more sophisticated step during this phase is to introduce dynamic
   routing at the E-NNI level.  This means that any neighboring networks
   (independent of internal switching capability) would be capable of
   exchanging routing information with peers across the E-NNI.

   Another alternative would be for private networks to bypass these
   intermediate steps and directly consider an integrated routing model
   from the onset.  This direct evolution strategy is realistic, but is
   more likely to occur in operational contexts where both the IP (or
   MPLS) and optical networks are built simultaneously, using equipment
   from a single source or from multiple sources that are closely
   affiliated.  In any case, due to the current lack of operational
   experience in managing this degree of control plane interaction in a
   heterogeneous network (these issues may exist even if the hardware
   and software originate from the same vendor), an augmented model is
   likely to be the most viable initial option.  Alternatively, a very
   modular or hierarchical peer model may be contemplated.  There may be
   other challenges (not just of a technical, but also administrative
   and even political issues) that may need to be resolved in order to
   achieve full a peer model at the routing level in a multi-technology
   and multi-vendor environment.  Ultimately, the main technical
   improvement would likely arise from efficiencies derived from the
   integration of traffic-engineering capabilities in the dynamic
   inter-domain routing environments.

9.  Security Considerations

   The architectural framework described in this document requires a
   number of different protocol mechanisms for its realization.
   Specifically, the role of neighbor discovery, routing, and signaling
   protocols were highlighted in previous sections.  The general
   security issues that arise with these protocols include:

   o  The authentication of entities exchanging information (e.g.,
      signaling, routing, or link management) across a control
Top   ToC   Page 42
   o  Ensuring the integrity of the information exchanged across the

   o  Protection of the control mechanisms from intrusions and other
      modes of outside interference.

   Because optical connections may carry high volumes of traffic and are
   generally quite expensive, mechanisms are required to safeguard
   optical networks against intrusions and unauthorized utilization of
   network resources.

   In addition to the security aspects relating to the control plane,
   the data plane must also be protected from external interference.

   An important consideration in optical networks is the separation of
   control channels from data channels.  This decoupling implies that
   the state of the bearer channels carrying user traffic cannot be
   inferred from the state of the control channels.  Similarly, the
   state of the control channels cannot be inferred from the state of
   the data channels.  The potential security implications of this
   decoupling should be taken into account in the design of pertinent
   control protocols and in the operation of IPO networks.

   Another issue in IPO networks concerns the fact that the underlying
   optical network elements may be invisible to IP client nodes,
   especially in the overlay model.  This means that traditional IP
   tools such as traceroute cannot be used by client IP nodes to detect
   attacks within the optical domain.

   For the aforementioned reasons, the output of the routing protocol
   security (RPSEC) efforts within the IETF should be considered in the
   design of control protocols for optical networks.

   In Section 2, the concept of a trust domain was defined as a network
   under a single technical administration in which adequate security
   measures are established to prevent unauthorized intrusion from
   outside the domain.  It should be strongly noted that within a trust
   domain, any subverted node can send control messages which can
   compromise the entire network.

9.1.  General security aspects

   Communication protocols usually require two main security mechanisms:
   authentication and confidentiality.  Authentication mechanisms ensure
   data origin verification and message integrity so that intrusions and
   unauthorized operations can be detected and mitigated.  For example,
   with reference to Figure 1, message authentication can prevent a
   malicious IP client from mounting a denial of service attack against
Top   ToC   Page 43
   the optical network by invoking an excessive number of connection
   creation requests across the UNI interface.  Another important
   security consideration is the need to reject replayed control
   packets.  This capability can assist in countering some forms of
   denial of service attacks.  Replay protection provides a form of
   partial sequence integrity, and can be implemented in conjunction
   with an authentication mechanism.

   Confidentiality of signaling messages is also desirable, especially
   in scenarios where message attributes between communicating entities
   include sensitive or private information.  Examples of such
   attributes include account numbers, contract identification
   information, and similar types of private data.

   The case of equipment that are not co-located presents increased
   security threats.  In such scenarios, the communicating entities
   engaged in protocol message transactions may be connected over an
   external network.  Generally, the external network may be outside the
   span of control of the optical network (or client IP network)
   administrators.  As a result, the protocol messages may be subject to
   increased security threats, such as address spoofing, eavesdropping,
   and intrusion.  To mitigate such threats, appropriate security
   mechanisms must be employed to protect the control channels and
   associated signaling and routing messages.

   Requests for optical connections from client networks must also be
   filtered using appropriate policies to protect against security
   infringements and excess resource consumption.  Additionally, there
   may be a need for confidentiality of SRLGs in some circumstances.

   Optical networks may also be subject to subtle forms of denial of
   service attacks.  An example of this would be requests for optical
   connections with explicit routes that induce a high degree of
   blocking for subsequent requests.  This aspect might require some
   global coordination of resource allocation.

   Another related form of subtle denial of service attack could occur
   when improbable optical paths are requested (i.e., paths within the
   network for which resources are insufficiently provisioned).  Such
   requests for improbable paths may consume ports on optical switching
   elements within the network resulting in denial of service for
   subsequent connection requests.
Top   ToC   Page 44
9.2.  Security Considerations for Protocol Mechanisms

   The security requirements for IP-centric control protocols employed
   in the control plane of optical networks would depend on the specific
   characteristics of the protocols and the security risks that exist in
   a particular operational context.  Such details relating to
   particular operational contexts are beyond the scope of this document
   and hence are not considered further.  Nevertheless, it must be
   stated that such control protocols must take into account the issues
   associated with the separation of control channels from data channels
   in switched optical networks, and the magnitude and extent of service
   interruptions  within the IP domain that could result from outages
   emanating from the optical domain.

10.  Summary and Conclusions

   The objective of this document was to define a framework for IP over
   optical networks, considering the service models, and routing and
   signaling issues.  There are a diversity of choices for IP-optical
   control interconnection, service models, and protocol mechanisms. The
   approach advocated in this document was to support different service
   models which allow for future enhancements, and define complementary
   signaling and routing mechanisms to enable these capabilities.  An
   evolutionary scenario, based on a common signaling framework (e.g.,
   based on GMPLS) was suggested, with the capability to increase the
   complexity of interworking functionality as the requirements become
   more sophisticated.  A key aspect of this evolutionary principle is
   that the IP-optical control and service interaction is first based on
   the domain services model with overlay interconnection that will
   eventually evolve to support full peer interaction.

11.  Informative References

   [1]   Awduche, D. and Y. Rekhter, "Multi-Protocol Lambda Switching:
         Combining MPLS Traffic Engineering Control With Optical
         Crossconnects", IEEE Communications Magazine, March 2001.

   [2]   Lang, J., et al., "Link Management Protocol", Work in progress.

   [3]   Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE",
         Internet Draft, Work in progress.

   [4]   Berger, L., Ed., "Generalized Multi-Protocol Label Switching
         (GMPLS) Signaling Functional Description", RFC 3471, January
Top   ToC   Page 45
   [5]   Rajagopalan, B., "Documentation of IANA Assignments for Label
         Distribution Protocol (LDP), Resource ReSeVation Protocol
         (RSVP), and Resource ReSeVation Protocol-Traffic Engineering
         (RSVP-TE) Extensions for Optical UNI Signaling", RFC 3476,
         March 2003.

   [6]   The Optical Interworking Forum, "UNI 1.0 Signaling
         Specification", December 2001.

   [7]   Kompella, K., et al., "OSPF Extensions in Support of
         Generalized MPLS," Work in Progress.

   [8]   Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP4)",
         RFC 1771, March 1995.

   [9]   Berger, L., Ed., "Generalized Multi-Protocol Label Switching
         (GMPLS) Signaling Resource ReSeVation Protocol-Traffic
         Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [10]  Mannie, E., "GMPLS Extensions for SONET/SDH Control", Work in

   [11]  Doshi, B., Dravida, S., Harshavardhana, P., et. al, "Optical
         Network Design and Restoration," Bell Labs Technical Journal,
         Jan-March, 1999.

   [12]  Kompella, K., et al., "Link Bundling in MPLS Traffic
         Engineering", Work in Progress.

   [13]  Ramamurthy, S., Bogdanowicz, Z., Samieian, S., et al.,
         "Capacity Performance of Dynamic Provisioning in Optical
         Networks", Journal of Lightwave Technology, January 2001.

   [14]  Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A
         Framework for QoS-based Routing in the Internet", RFC 2386,
         August 1998.

   [15]  Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V.
         Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
         3209, December 2001.

   [16]  Suurballe, J., "Disjoint Paths in a Network", Networks, vol. 4,

   [17]  Chiu, A., et al., "Impairments and Other Constraints On Optical
         Layer Routing", Work in Progress.
Top   ToC   Page 46
12.  Acknowledgments

   We would like to thank Zouheir Mansourati (Movaz Networks), Ian
   Duncan (Nortel Networks), Dimitri Papadimitriou (Alcatel), and
   Dimitrios Pendarakis (Tellium) for their contributions to this
   document.  The Security Considerations section was revised to reflect
   input from Scott Bradner and Steve Bellovin.

13.  Contributors

   Contributors are listed alphabetically.

   Brad Cain
   Cereva Networks
   3 Network Dr.
   Marlborough, MA 01752


   Bilel Jamoussi
   Nortel Networks
   600 Tech Park
   Billerica, MA 01821

   Phone: 978-288-4734

   Debanjan Saha

Top   ToC   Page 47
14.  Authors' Addresses

   Bala Rajagopalan
   Tellium, Inc.
   2 Crescent Place
   P.O. Box 901
   Oceanport, NJ 07757-0901


   James V. Luciani
   Marconi Communications
   2000 Marconi Dr.
   Warrendale, PA 15086


   Daniel O. Awduche
   22001 Loudoun County Parkway
   Ashburn, VA 20147

   Phone: 703-886-1753
Top   ToC   Page 48
15.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to
   rights in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at


   Funding for the RFC Editor function is currently provided by the
   Internet Society.