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.