RFC 3717
IP over Optical Networks: A Framework
Pages: 48
Informational
Informational
Part 2 of 2 – Pages 25 to 48
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 networks.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.
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, identification. 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).
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 computation.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].
+--------------+ +------------+ +------------+ | +-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 SRLGs6.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.
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
paths.
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
overhead.
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
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 information:
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
recomputed.
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
information.
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
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.
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 down. 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 paths.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.
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 certain. 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.
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
internetwork.
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.
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
elements, even though non-IP paths may exist between the peering routers.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 clients. 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
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
parameterize the characteristics of these components and advertise them within the control plane. This aspect is left for further study.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.
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).
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 interface;
o Ensuring the integrity of the information exchanged across the
interface;
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
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.
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 2003.
[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 Progress. [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, 1974. [17] Chiu, A., et al., "Impairments and Other Constraints On Optical Layer Routing", Work in Progress.
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 EMail: bcain@cereva.com Bilel Jamoussi Nortel Networks 600 Tech Park Billerica, MA 01821 Phone: 978-288-4734 EMail: jamoussi@nortelnetworks.com Debanjan Saha EMail: debanjan@acm.org
14. Authors' Addresses
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 EMail: braja@tellium.com James V. Luciani Marconi Communications 2000 Marconi Dr. Warrendale, PA 15086 EMail: james_luciani@mindspring.com Daniel O. Awduche MCI 22001 Loudoun County Parkway Ashburn, VA 20147 Phone: 703-886-1753 EMail: awduche@awduche.com
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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 at http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.