RFC 3717
IP over Optical Networks: A Framework
RFC 3717: IP over Optical Networks: A Framework 💖
Okay bestie, let's start with the title block 🎀 This one was written by B. Rajagopalan (a Consultant), J. Luciani (from Marconi Communications), and D. Awduche (from MCI) ✨. It's dated March 2004, and its category is Informational 🦋, which means it's here to give the Internet community information, not to be a standard. It doesn't list anything it obsoletes or updates, so no drama there 💅.
Status of This Memo 📜
Okay so this memo is here to share information with the Internet community 📚. It doesn't specify any Internet standard, not even a little bit. And distribution? Totally unlimited 🌈
Copyright Notice ©️
The Internet Society holds the copyright on this (2004), and all rights are reserved 💜
Abstract 🌸
The Internet's transport infrastructure is heading toward a look where high-speed routers are connected by optical core networks 🚀. The architectural choices for how IP and optical network layers interact, especially the routing and signaling parts, are getting more mature every day 🧠. At the same time, the industry has pretty much agreed on using IP-based protocols for the optical control plane, and that's so iconic 👑. This document sets up a framework for IP over Optical networks. It covers both the IP-based control plane for optical networks and the interactions between IP and optical networks (together called "IP over optical networks") 🫶.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4
3. The Network Model. . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Network Interconnection. . . . . . . . . . . . . . . . . 8
3.2. Control Structure. . . . . . . . . . . . . . . . . . . . 11
4. IP over Optical Service Models and Requirements. . . . . . . . 13
4.1. Domain Services Model. . . . . . . . . . . . . . . . . . 13
4.2. Unified Service Model. . . . . . . . . . . . . . . . . . 14
4.3. Which Service Model? . . . . . . . . . . . . . . . . . . 15
4.4. What are the Possible Services?. . . . . . . . . . . . . 16
5. IP transport over Optical Networks . . . . . . . . . . . . . . 16
5.1. Interconnection Models . . . . . . . . . . . . . . . . . 17
5.2. Routing Approaches . . . . . . . . . . . . . . . . . . . 18
5.3. Signaling-Related. . . . . . . . . . . . . . . . . . . . 21
5.4. End-to-End Protection Models . . . . . . . . . . . . . . 23
6. IP-based Optical Control Plane Issues. . . . . . . . . . . . . 25
6.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 27
6.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 28
6.4. Protection and Restoration Models. . . . . . . . . . . . 29
6.5. Route Computation. . . . . . . . . . . . . . . . . . . . 30
6.6. Signaling Issues . . . . . . . . . . . . . . . . . . . . 32
6.7. Optical Internetworking. . . . . . . . . . . . . . . . . 34
7. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. WDM and TDM in the Same Network. . . . . . . . . . . . . 35
7.2. Wavelength Conversion. . . . . . . . . . . . . . . . . . 36
7.3. Service Provider Peering Points. . . . . . . . . . . . . 36
7.4. Rate of Lightpath Set-Up . . . . . . . . . . . . . . . . 36
7.5. Distributed vs. Centralized Provisioning . . . . . . . . 37
7.6. Optical Networks with Additional Configurable
Components . . . . . . . . . . . . . . . . . . . . . . . 38
7.7. Optical Networks with Limited Wavelength Conversion
Capability . . . . . . . . . . . . . . . . . . . . . . . 38
8. Evolution Path for IP over Optical Architecture. . . . . . . . 39
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
9.1. General Security Aspects . . . . . . . . . . . . . . . . 42
9.2. Security Considerations for Protocol Mechanisms. . . . . 43
10. Summary and Conclusions. . . . . . . . . . . . . . . . . . . . 44
11. Informative References . . . . . . . . . . . . . . . . . . . . 44
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 45
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 481. Introduction ✨
Optical network tech is evolving super fast in terms of its functions and capabilities 🚀. You can tell how important optical networks have become from the huge amount of attention on IP over optical networks and related photonic and electronic interworking issues from every major network service provider, telecom equipment vendor, and standards organization 👑. In practice, "optical network" is used generically to mean both SONET/SDH-based transport networks and switched optical networks (including all-optical networks) 🦋.
It's been realized that optical networks must be survivable, flexible, and controllable 💪. So there's an ongoing trend to put intelligence into the control plane of optical networks to make them more versatile [1] 🧠. An essential attribute of intelligent optical networks is being able to set up and route optical layer connections in real-time or near real-time, and to provide capabilities that boost network survivability ⚡. Plus, there's a need for multi-vendor optical network interoperability, since an optical network may be made up of interconnected vendor-specific optical sub-networks 🌈.
The optical network must also be versatile, because some service providers may offer generic optical layer services that may not be client-specific 💅. That means we need an optical network control plane that can handle those generic optical services 🫶.
The industry is pretty much in agreement that the optical network control plane should use IP-based protocols for dynamic provisioning and restoration of optical channels within and across optical sub-networks 🎀. The thinking is practical: signaling and routing mechanisms built for IP traffic engineering applications could be reused in optical networks 🔁. Still, the issues and requirements specific to optical networking must be understood so the IP-based protocols can be suitably adopted and adapted 🧐. This is especially true for restoration, and for routing and signaling in all-optical networks 💜. There are also different views on the model for interaction between the optical network and client networks, like IP networks. Reasonable architectural alternatives must be supported, with an understanding of their relative merits 🌸.
So, there are two fundamental issues with IP over optical networks 👀. The first is the adaptation and reuse of IP control plane protocols within the optical network control plane, no matter which types of digital clients use the optical network 🧚. The second is carrying IP traffic through an optical network, along with the control and coordination issues that come with it 🍓.
This document defines a framework for IP over optical networks. It covers the requirements and mechanisms for establishing an IP-centric optical control plane, plus the architectural aspects of IP transport over optical networks 🦋. The specific capabilities needed for IP over optical networks depend on the services expected at the IP-optical interface as well as the optical sub-network interfaces. Depending on the operational requirements, there can be a progression of capabilities, reflecting increasingly sophisticated interactions at these interfaces 📈. That's why this document advocates defining "capability sets" that describe how functionality at the interfaces evolves as more sophisticated operational requirements show up 👑.
Here's how this document is organized 🗺️. The next section describes terminology covering some basic concepts related to this framework. These definitions are specific to this framework and may have other connotations elsewhere 📖. Section 3 describes the network model that's relevant to this framework 🌐. The service model and requirements for IP-optical and multi-vendor optical internetworking are in Section 4, which also looks at some general requirements 💖. Section 5 covers the architectural models for IP-optical interworking and describes the relative merits of each one. It should be noted that this document is not trying to promote any particular model over the others. However, particular aspects that may make one approach more appropriate than another in certain circumstances are described ⚖️. Section 6 describes IP-centric control plane mechanisms for optical networks, covering signaling and routing issues in support of provisioning and restoration 🛠️. The approaches in Section 5 and 6 range from relatively simple to sophisticated 🌟. Section 7 describes a number of specialized issues related to IP over optical networks 🔍. Section 8 describes a possible evolution path for IP over optical networking capabilities, in terms of increasingly sophisticated functionality that may be supported as the need arises 🦄. Section 9 considers security issues pertinent to this framework 🔐. Finally, the summary and conclusion are in Section 10 🎉.
2. Terminology and Concepts ✨
okay bestie, this section is where we get our vocab straight 🎀 the definitions here are specific to this framework, so they might mean something different in other places, so don't assume 🙈
WDM 🌈
Wavelength Division Multiplexing (WDM) is a technology that lets multiple optical signals, each at a different wavelength, get multiplexed onto one single optical fiber and sent in parallel through it. 🦋 Each wavelength can carry digital client payloads at a different data rate (like OC-3c, OC-12c, OC-48c, OC-192c, and so on) and in a different format (SONET, Ethernet, ATM, etc.). For example, there are lots of commercial WDM networks out there today that run a mix of SONET signals at OC-48c (roughly 2.5 Gbps) and OC-192 (roughly 10 Gbps) over a single fiber. 😭 An optical system with WDM capability can do parallel transmission of multiple wavelengths gracefully while keeping high system performance and reliability. In the near future, commercial dense WDM systems are expected to carry more than 160 wavelengths at OC-192c and above, which adds up to 1.6 Tbps or more. 💖 The term WDM is used in this document to mean both WDM and DWDM (Dense WDM).
In general, WDM links are affected by the following factors, which may introduce impairments into the optical signal path:
- The number of wavelengths on a single fiber.
- The serial bit rate per wavelength.
- The type of fiber.
- The amplification mechanism.
- The number and type of nodes through which the signals pass before reaching the egress node or before regeneration.
All of these factors (and others not mentioned here) are domain specific features of optical transport networks. 🔥 As noted in [1], these features should be taken into account when developing standards based solutions for IP over optical networks. main character energy, honestly 💅
Optical cross-connect (OXC) 🔌
An OXC is a space-division switch that can switch an optical data stream from an input port to an output port. ✨ That switch might use optical-electrical conversion at the input port and electrical-optical conversion at the output port, or it might be all-optical. 🧚 An OXC is assumed to have a control-plane processor that implements the signaling and routing protocols needed to compute and set up optical channel connectivity in the optical domain.
Optical channel trail or Lightpath 🛤️
An optical channel trail is a point-to-point optical layer connection between two access points in an optical network. 💜 In this document, the term "lightpath" is used interchangeably with optical channel trail, so they're the same thing, bestie.
Optical mesh sub-network 🕸️
An optical sub-network, as used in this framework, is a network of OXCs that supports end-to-end networking of optical channel trails. It gives you functionality like routing, monitoring, grooming, and protection and restoration of optical channels. 🌸 The OXCs in this network can be interconnected in a general mesh topology. This network may have the following sub-layers associated with it:
- (a) An optical multiplex section (OMS) layer network: The optical multiplex section layer provides transport for the optical channels. The information in this layer is a data stream made up of a set of optical channels, which may have a defined aggregate bandwidth.
- (b) An optical transmission section (OTS) layer network: This layer provides functionality for transmitting optical signals through different types of optical media. 🎀
This framework does not address the interaction between the optical sub-network and the OMS, or between the OMS and OTS layer networks. 🙃
Mesh optical network (or simply, "optical network") 🌐
A mesh optical network, as used in document, is a topologically connected collection of optical sub-networks whose node degree may exceed 2. 🍓 An optical network like this is assumed to be under the purview of a single administrative entity. It's also possible to picture a large scale global mesh optical network made up of the voluntary interconnection of autonomous optical networks, where each one is owned and administered by an independent entity. In that kind of setup, abstraction can be used to hide the internal details of each autonomous optical cloud from external clouds. the way that abstraction is doing the most here 🫶
Optical internetwork 🌍
An optical internetwork is a mesh-connected collection of optical networks. Each of these networks may be under a different administration. 👑
Wavelength continuity property 🌈
A lightpath is said to satisfy the wavelength continuity property if it is transported over the same wavelength end-to-end. Wavelength continuity is required in optical networks that have no wavelength conversion feature. 🦋
Wavelength path ⭐
A lightpath that satisfies the wavelength continuity property is called a wavelength path. simple, iconic, done 💅
Opaque vs. transparent optical networks 🔍
A transparent optical network is an optical network in which optical signals are transported from transmitter to receiver entirely in the optical domain, with no OEO conversion. 🧚 Generally, intermediate switching nodes in a transparent optical network do not have access to the payload carried by the optical signals. 🙈
Note that amplification of signals at transit nodes is permitted in transparent optical networks (for example, using Erbium Doped Fiber Amplifiers (EDFAs)). ✨
On the other hand, in opaque optical networks, transit nodes may manipulate the optical signals traversing through them. 💀 An example of that manipulation is OEO conversion, which may involve 3R operations (reshaping, retiming, regeneration, and perhaps amplification).
Trust domain 🛡️
A trust domain is a network under a single technical administration in which adequate security measures are established to prevent unauthorized intrusion from outside the domain. 🫶 Hence, it may be assumed that most nodes in the domain are deemed to be secure or trusted in some fashion. Generally, the rule for "single" administrative control over a trust domain may be relaxed in practice if a set of administrative entities agree to trust one another and form an enlarged heterogeneous trust domain. However, to simplify the discussions in this document, it will be assumed, without loss of generality, that the term trust domain applies to a single administrative entity with appropriate security policies.
⚠️ bestie, this part is serious: within a trust domain, any subverted node can send control messages which can compromise the entire network. one bad node, whole network gone 😭 so protect those control messages like your life depends on it, because it does 💀
Flow 🌊
In this document, the term flow is used to signify the smallest non-separable stream of data, from the point of view of an endpoint or termination point (source or destination node). 🌸 The reader should note that the term flow is heavily overloaded in contemporary networking literature, so it can mean a bunch of different things 🙃 In this document, we will consider a wavelength to be a flow, under certain circumstances. However, if there is a method to partition the bandwidth of the wavelength, then each partition may be considered a flow. For example, using time division multiplexing (TDM), it may be feasible to consider each quanta of time within a given wavelength as a flow. 🧚
Traffic Trunk 🚂
A traffic trunk is an abstraction of traffic flow traversing the same path between two access points, which allows some characteristics and attributes of the traffic to be parameterized. 💖 It's basically a neat little bundle of traffic that shares a path, with its vibes written down. ✨
3. The Network Model 🦋
3.1. Network Interconnection 🌐✨
Okay bestie, so the network model we're vibing with is IP routers sitting on top of an optical core internetwork, and each router connects to its peers over switched optical channels that get set up dynamically 🦋. The big thing to know is that the optical core is assumed to be incapable of processing individual IP packets in the data plane. It just moves light around and never reads your packets 💅.
The optical internetwork is made of multiple optical networks, and each one might be run by a different entity 👑. Each optical network is sub-networks connected by optical fiber links in a general topology, which is what they call an optical mesh network 🕸️. That network can have re-configurable optical gear from a single vendor or from multiple vendors 🌈. In the near term, each sub-network is expected to be switches from one vendor. Later on, once standardization efforts mature, one optical sub-network might contain optical switches from different vendors ⭐. Either way, each sub-network is assumed to be mesh-connected internally. Topologically adjacent OXCs in an optical mesh network can generally be expected to be connected via multiple, parallel (bi-directional) optical links. Figure 1 shows the whole model 👇
Optical Network
+---------------------------------------+
| |
| Optical Subnetwork |
+---------+ | +-----------------------------------+ |
| | | | +-----+ +-----+ +-----+ | |
| IP | | | | | | | | | | |
| Network +-UNI --+-+ OXC +------+ OXC +------+ OXC + | |
| | | | | | | | | | | |
+---------+ | | +--+--+ +--+--+ +--+--+ | |
| +----|------------|------------|----+ |
| | | | |
| INNI INNI INNI |
+---------+ | | | | |
| | | +----+------+ | +-------+----+ |
| IP + UNI- | | +-----+ | | |
| Network | | | Optical | | Optical | |
| | | |Subnetwork +---INNI---+ Subnetwork | |
+---------+ | | | | | |
| +-----+-----+ +------+-----+ |
| | | |
+-------+-----------------------+-------+
| |
ENNI ENNI
| |
+-------+-----------------------+-------+
| |
| Optical Network |
| |
+-------+-----------------------+-------+
| |
UNI UNI
| |
+-----+----- --+ +-----+------+
| | | |
| Other Client | |Other Client|
| Network | | Network |
| (e.g., ATM) | | |
+- ------------+ +------------+
Figure 1: Optical Internetwork ModelNow the "edge routers" bit 🦄. The routers that have direct physical connectivity with the optical network are called "edge routers" with respect to that optical network. And as Figure 1 shows, other client networks (like ATM) can also plug into the optical network 🎀.
The switching function in an OXC is controlled by configuring the cross-connect fabric. Conceptually, you can picture a cross-connect table with entries like <input port i, output port j>, which means the data stream coming into input port i gets switched out to output port j 🍓. For a wavelength selective cross-connect (usually called a WXC), the table can also list the input and output wavelengths along with the ports 🌸. To set up a lightpath from an ingress port in one OXC to an egress port in a remote OXC, you configure cross-connects in the ingress, the egress, and a set of intermediate OXCs, so that a continuous physical path exists from ingress to egress 🧚.
Optical paths tend to be bi-directional 🔄. That means the return path from the egress port back to the ingress port usually goes through the same set of intermediate interface cards as the forward path, but that's not guaranteed in every situation 🙈.
Multiple traffic streams leaving an OXC can be multiplexed onto a fiber optic link using WDM technology 💜. The WDM functionality can live outside the OXC and be transparent to it, or it can be built right into the OXC. In that second case, the cross-connect table conceptually holds pairs of the form <{input port i, Lambda(j)}, {output port k, Lambda(l)}>, which means the data stream received on wavelength Lambda(j) over input port i is switched to output port k on Lambda(l) ✨. Automated lightpath setup means programming the cross-connect table entries in the right OXCs in a coordinated way, so the desired physical path actually gets realized 🫶.
Here's the important part 🚨. Under this network model, a switched lightpath must be established between a pair of IP routers before those routers can transfer user traffic between themselves. And a lightpath between IP routers may traverse multiple optical networks, with different provisioning and restoration procedures in each one 😭.
So the IP-based control plane issue for optical networks is designing standard signaling and routing protocols for provisioning and restoring lightpaths across multiple optical networks 🔥. Similarly, IP transport over optical networks is about establishing IP reachability and seamlessly building forwarding paths from one IP endpoint to another across an optical network 👑💅.
3.2. Control Structure
okay bestie, Figure 1 has three logical control interfaces 🦋. First is the client-optical internetwork interface. Second is the internal node-to-node interface inside an optical network, between OXCs in different sub-networks. Third is the external node-to-node interface between nodes in different optical networks. People also call these the User-Network Interface (UNI), the internal NNI (INNI), and the external NNI (ENNI), respectively 💅
The reason they're split up is the type and amount of control info flowing across each one 💖 The client-optical interface (UNI) is a service boundary between the client (e.g., IP router) and the optical network. The client and server (the optical network) are basically two different roles. The client role requests a service connection from a server, and the server role sets up that connection to fulfill the request, provided all relevant admission control conditions are satisfied 🫶
So the control flow across the client-optical interface depends on the set of services defined across it and how those services can be accessed ✨ The service models are in Section 4. The NNIs are vendor-independent standardized interfaces for control flow between nodes 🌸 The difference between the INNI and ENNI is that the INNI lives inside one network under a single technical administration, while the ENNI sits at the administrative boundary between networks. That means they can differ in the policies that restrict control flow between nodes 👑
Security, scalability, stability, and information hiding are a big deal when it comes to the ENNI 🙈 In principle, it's possible to harmonize control flow across the UNI and the NNI and eliminate the distinction between them. On the other hand, it may be required to minimize the flow of control information, especially routing-related information, over the UNI and even over the ENNI 😭 In that case, the UNI and NNIs may look different in some respects. In this document, these interfaces are treated as distinct 🧚
The client-optical internetwork interface can be categorized as public or private, depending on context and service models 💜 Routing information (i.e., topology state information) can be exchanged across a private client-optical internetwork interface. On a public one, that info is not exchanged, or it may be exchanged with very explicit restrictions (including, for example, abstraction, filtration, etc). So different relationships (e.g., peer or over-lay, Section 5) may occur across private and public logical interfaces 🌈
The physical control structure used to realize these logical interfaces may vary. For the client-optical internetwork interface, some of the possibilities are:
- Direct interface: An in-band or out-of-band IP control channel (IPCC) may be implemented between an edge router and each OXC it's connected to. This control channel is used for exchanging signaling and routing messages between the router and the OXC. With a direct interface, the edge router and the OXC it connects to are peers with respect to the control plane. This situation is shown in Figure 2. The type of routing and signaling information exchanged across the direct interface may vary depending on the service definition, and this issue is addressed in the next section. Some choices for the routing protocol are OSPF or ISIS (with traffic engineering extensions and additional enhancements to deal with the peculiar characteristics of optical networks) or BGP, or some other protocol. Other directory-based routing information exchanges are also possible. Some of the signaling protocol choices are adaptations of RSVP-TE or CR-LDP. The details of how the IP control channel is realized are outside the scope of this document 🎀
- Indirect interface: An out-of-band IP control channel may be implemented between the client and a device in the optical network to signal service requests and responses. For instance, a management system or a server in the optical network may receive service requests from clients. Similarly, out-of-band signaling may be used between management systems in client and optical networks to signal service requests. In these cases, there is no direct control interaction between clients and their respective OXCs. One reason to have an indirect interface would be that the OXCs and/or clients don't support a direct signaling interface 🍓
- Provisioned interface: In this case, the optical network services are manually provisioned, and there are no control interactions between the client and the optical network 💀
+---------------------------+ +---------------------------+
| | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | | | | | |
| | Routing | |Signaling| | | | Routing | |Signaling| |
| | Protocol| |Protocol | | | | Protocol| |Protocol | |
| | | | | | | | | | | |
| +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ |
| | | | | | | |
| | | | | | | |
| +--+-----------+---+ | | +--+-----------+---+ |
| | | | | | | |
| | IP Layer +....IPCC.....+ IP Layer | |
| | | | | | | |
| +------------------+ | | +------------------+ |
| | | |
| Edge Router | | OXC |
+---------------------------+ +---------------------------+
Figure 2: Direct InterfaceAlthough different control structures are possible, the rest of this framework assumes direct interfaces for IP-optical and optical sub-network control interactions 💖
4. IP over Optical Service Models and Requirements ✨
In this section, we look at the service models and requirements at the UNI and the NNIs 🌷 Two general models have emerged for the services at the UNI (and they can also be applied at the NNIs). Here they are 👇
4.1. Domain Services Model
Under the domain services model, the optical network mainly offers high bandwidth connectivity in the form of lightpaths 💡 Standardized signaling across the UNI (Figure 1) is used to invoke the following services:
- Lightpath creation: This service allows a lightpath with the specified attributes to be created between a pair of termination points in the optical network. Lightpath creation may be subject to network-defined policies (e.g., connectivity restrictions) and security procedures 🔐
- Lightpath deletion: This service allows an existing lightpath to be deleted 🗑️
- Lightpath modification: This service allows certain parameters of the lightpath to be modified 🛠️
- Lightpath status enquiry: This service allows the status of certain parameters of the lightpath (referenced by its ID) to be queried by the router that created the lightpath 👀
An end-system discovery procedure may be used over the UNI to verify local port connectivity between the optical and client devices, and it allows each device to bootstrap the UNI control channel. Finally, a "service discovery" procedure may be used as a precursor to obtaining UNI services. Service discovery lets a client determine the static parameters of the interconnection with the optical network, including the UNI signaling protocols supported 🔍 The protocols for neighbor and service discovery are different from the UNI signaling protocol itself (for example, see LMP [2]).
Because a small set of well-defined services is offered across the UNI, the signaling protocol requirements are minimal 🌸 Specifically, the signaling protocol is required to convey a few messages with certain attributes in a point-to-point manner between the router and the optical network. Such a protocol may be based on RSVP-TE or LDP, for example.
The optical domain services model doesn't deal with the type and nature of routing protocols within and across optical networks 🙅
The optical domain services model would result in the establishment of a lightpath topology between routers at the edge of the optical network 🦋 The resulting overlay model for IP over optical networks is discussed in Section 5.
4.2. Unified Service Model
Under this model, the IP and optical networks are treated together as a single integrated network from a control plane point of view 🫶 In this regard, the OXCs are treated just like any other router as far as the control plane is concerned. So in principle, there is no distinction between the UNI, the NNIs, and any other router-to-router interface from a routing and signaling point of view. It is assumed that this control plane is IP-based, for example leveraging the traffic engineering extensions for MPLS or GMPLS, as described in [1]. The unified service model has so far only been discussed in the context of a single administrative domain. A unified control plane is possible even when there are administrative boundaries within an optical internetwork, but some of the integrated routing capabilities may not be practically attractive or even feasible in this case (see Section 5) 🤔
Under the unified service model, and within the context of a GMPLS network, optical network services are obtained implicitly during end-to-end GMPLS signaling 🧠 Specifically, an edge router can create a lightpath with specified attributes, or delete and modify lightpaths, as it creates GMPLS label-switched paths (LSPs). In this regard, the services obtained from the optical network are similar to the domain services model. These services, however, may be invoked in a more seamless manner compared to the domain services model 🌈 For instance, when routers are attached to a single optical network (i.e., there are no ENNIs), a remote router could compute an end-to-end path across the optical internetwork. It can then establish an LSP across the optical internetwork. But the edge routers must still recognize that an LSP across the optical internetwork is a lightpath, or a conduit for multiple packet-based LSPs 💅
The concept of "forwarding adjacency" can be used to specify virtual links across optical internetworks in routing protocols such as OSPF [3] 💖 Essentially, once a lightpath is established across an optical internetwork between two edge routers, the lightpath can be advertised as a forwarding adjacency (a virtual link) between those routers. So from a data plane point of view, the lightpaths result in a virtual overlay between edge routers 🦋 The decisions about when to create such lightpaths, and the bandwidth management for these lightpaths, are identical in both the domain services model and the unified service model. The routing and signaling models for unified services are described in Sections 5 and 6 ✨
4.3. Which Service Model? 💅
okay so the pros and cons of these service models could be debated forever 😭, but the approach this framework recommends is to define routing and signaling mechanisms that support both models 🫶. like we said above, signaling for service requests can be unified to cover both. the GMPLS signaling work [4] for the unified service model, and its adoption for UNI signaling [5, 6] under the domain services model, basically backs this up ✨. the big difference between the service models, though, is in routing protocols, as described in Sections 5 and 6 🔥.
4.4. What are the Possible Services?
specialized services can be built on top of the point-to-point connectivity service the optical network offers 🌸. for example, optical virtual private networks and bandwidth on demand are some of the services we can totally envision 🦋.
4.4.1. Optical Virtual Private Networks (OVPNs)
so the data plane links between IP routers over an optical network amount to a virtual topology, an overlay on top of the fiber optic network 🕸️. that makes it easy to picture a virtual private network of lightpaths that interconnect routers (or any other set of clients) belonging to a single entity or a group of related entities, across a public optical network 💜. and ngl, if the optical network provides connectivity for multiple sets of external client networks, there has to be a way to enforce routing policies that keep routing separate between those different sets of client networks (aka VPN service) 🔐.
5. IP transport over Optical Networks 🌈
okay bestie, to look at the architectural options for IP over optical networks, we have to tell the data plane and the control plane apart 🧚. the optical network gives external entities a service in the form of fixed bandwidth transport pipes (optical paths) 🍓. IP routers at the edge of the optical networks must necessarily have those paths set up between them before anything can start talking at the IP layer 😭. so the IP data plane over optical networks is realized over a virtual topology of optical paths. on the other hand, IP routers and OXCs can have a peer relation when it comes to the control plane, especially for routing protocols that permit the dynamic discovery of IP endpoints attached to the optical network ✨.
the IP over optical network architecture is basically defined by how the control plane is organized 👑. this framework assumes an IP-based control plane [1] is used, such as GMPLS. depending on the service model (Section 4), though, the control planes in the IP and optical networks can be loosely or tightly coupled 💖. this coupling decides the following characteristics:
- The details of the topology and routing information advertised by the optical network across the client interface;
- The level of control that IP routers can exercise in selecting explicit paths for connections across the optical network;
- Policies regarding the dynamic provisioning of optical paths between routers. These include access control, accounting, and security issues.
the following interconnection models are then possible 🦋:
5.1. Interconnection Models
5.1.1. The Peer Model
under the peer model, the IP control plane acts as a peer of the optical transport network control plane 🫶. this means a single instance of the control plane is deployed over the IP and optical domains. when there's a single optical network involved and the IP and optical domains belong to the same entity, then a common IGP such as OSPF or IS-IS, with appropriate extensions, can be used to distribute topology information [7] over the integrated IP-optical network 🔥. with OSPF, opaque LSAs can be used to advertise topology state information. with IS-IS, extended TLVs will have to be defined to propagate topology state information. honestly, a lot of these extensions are happening within the context of GMPLS 💅.
when an optical internetwork with multiple optical networks is involved (for example, one spanning different administrative domains), a single instance of an intra-domain routing protocol is not attractive or even realistic 😭. in this case, inter-domain routing and signaling protocols are needed. either way, there's a tacit assumption that a common addressing scheme will be used for the optical and IP networks 🌸. a common address space can be trivially realized by using IP addresses in both the IP and optical domains. so the optical network elements become IP addressable entities, as noted in [1] 🧚.
5.1.2. The Overlay Model
under the overlay model, the IP layer routing, topology distribution, and signaling protocols are independent of the routing, topology distribution, and signaling protocols within the optical domain 🌈. this is conceptually similar to the classic IP over ATM or MPOA models, just applied to an optical internetwork instead 💜. in the overlay model, a separate instance of the control plane (especially the routing and signaling protocols) would have to be deployed in the optical domain, independent of what exists in the IP domain. in certain circumstances, it may also be feasible to statically configure the optical channels that provide connectivity for the IP domain 🍓. static configuration can be done through network management functions. static configuration, however, is unlikely to scale in very large networks, and may not support the rapid connection provisioning requirements of future highly competitive networking environments 💀.
5.1.3. The Augmented Model
under the augmented model, there are separate routing instances in the IP and optical domains, but certain types of information from one routing instance can be passed through to the other one 🦋. for example, external IP addresses could be carried within the optical routing protocols so reachability information can be passed to IP clients ✨.
the routing approaches that match these interconnection models are described below 👑.
5.2. Routing Approaches
5.2.1. Integrated Routing
this routing approach supports the peer model within a single administrative domain 🫶. under this approach, the IP and optical networks are assumed to run the same instance of an IP routing protocol, e.g., OSPF with suitable "optical" extensions. these extensions must capture optical link parameters, and any constraints that are specific to optical networks 🔥. the topology and link state information maintained by all nodes (OXCs and routers) may be identical, but not necessarily 💅. this approach lets a router compute an end-to-end path to another router across the optical network.
say the path computation is triggered by the need to route a label switched path (LSP) in a GMPLS environment 😭. an LSP like that can be established using GMPLS signaling, e.g., RSVP-TE or CR-LDP with appropriate extensions. in this case, the signaling protocol will establish a lightpath between two edge routers. this lightpath is in essence a tunnel across the optical network, and it may have much more capacity than the bandwidth needed to support the first LSP 🌸. so it's essential that other routers in the network realize the excess capacity within the lightpath is available, so later LSPs between the routers can use it instead of instantiating a new lightpath 🧚. the lightpath may therefore be advertised as a virtual link in the topology, as a means to address this issue ✨.
the notion of "forwarding adjacency" (FA), described in [3], is essential for propagating existing lightpath information to other routers 💖. an FA is essentially a virtual link advertised into a link state routing protocol. so an FA could be described by the same parameters that define resources in any regular link 🦋. while it's necessary to specify the mechanism for creating an FA, it's not necessary to specify how an FA gets used by the routing scheme. once an FA is advertised in a link state protocol, its usage for routing LSPs is defined by the route computation and traffic engineering algorithms implemented 👑.
it should be noted that at the IP-optical interface, the physical ports over which routers connect to OXCs constrain the connectivity and resource availability 🌈. say a router R1 is connected to OXC O1 over two ports, P1 and P2. under integrated routing, the connectivity between R1 and O1 over the two ports would have been captured in the link state representation of the network. now, say an FA at full port bandwidth is created from R1 to another router R2 over port P1. while this FA is advertised as a virtual link between R1 and R2, it's also necessary to remove the link R1-O1 (over P1) from the link state representation, since that port is no longer available for creating a lightpath 💀. so as FAs get created, an overlaid set of virtual links is introduced into the link state representation, replacing the links previously advertised at the IP-optical interface 😭. finally, the details of the optical network captured in the link state representation are replaced by a network of FAs. the scheme above is one way to tackle the problem. another approach is to associate appropriate dynamic attributes with link state information, so that a link that cannot be used to establish a particular type of connection will be tagged appropriately 🍓. generally, though, there's a great deal of similarity between integrated routing and domain-specific routing (described next). both ultimately deal with creating a virtual lightpath topology (overlaid over the optical network) to meet certain traffic engineering objectives 💜.
5.2.2. Domain-Specific Routing
the domain-specific routing approach supports the augmented interconnection model 🫶. under this approach, routing within the optical and IP domains is separated, with a standard routing protocol running between domains. this is similar to the IP inter-domain routing model. a specific approach for this is considered next. it's to be noted that other approaches are equally possible 🌸.
5.2.2.1. Domain-Specific Routing using BGP
okay bestie, so BGP [8] is the inter-domain IP routing protocol, and it may be adapted to swap routing info between IP and optical domains 🌸 That means routers can advertise their IP address prefixes into the optical internetwork and also receive external IP address prefixes back from it. The optical internetwork carries the reachability info from one IP network over to the others, which is literally so iconic 🦋 For example, edge routers and OXCs can run exterior BGP (EBGP). Inside the optical internetwork, interior BGP (IBGP) may be used between border optical switches, and EBGP may be used between different networks (over ENNI, Figure 1). 💅
Under this setup, it may be necessary to figure out the egress points in the optical internetwork that match up with externally reachable IP addresses. Let me explain 🧚 Say an edge router wants an LSP to a destination across the optical internetwork. It may request a direct lightpath to that destination without naming the egress optical port, because the optical internetwork already knows which external IP addresses are reachable. BUT if that same edge router wants another LSP to a different external destination, then for efficiency it may first need to check whether there's already a lightpath (with enough residual capacity) to that target. So edge routers may need to keep track of which egress ports in the optical internetwork lead to which external destinations 👀 Now, a border OXC that gets external IP prefixes from an edge router over EBGP must include its own IP address as the egress point before passing those prefixes along to other border OXCs or edge routers. An edge router that receives this info doesn't need to pass the egress address any further, but it must keep the association between external IP addresses and egress OXC addresses. And when optical VPNs are implemented, the address prefixes advertised by the border OXCs may come with some VPN specific identification. 🎀
Now the not-so-cute part 🙈 Using domain-specific routing with BGP in an IPO environment can have some potential negative effects:
- The amount of information that optical nodes will have to maintain will not be bound by the size of the optical network anymore, but will have to include external routes as well. ngl that's a lot of extra baggage 💀
- The stability of the optical network control plane will no longer be dictated solely by the dynamics emanating within the optical network, but may be affected by the dynamics originating from external routing domains from which external reachability information is received. so the optical side's stability is now partly at the mercy of other people's networks 😭
5.2.3. Overlay Routing
okay so overlay routing is the approach that supports the overlay interconnection model ✨ Here's the vibe: an overlay mechanism gets implemented that lets edge routers register and query for external addresses 💖 It's conceptually similar to the address resolution mechanism used for IP over ATM, so if you know that, you're already halfway there 🧚 The optical network could run a registry where edge routers register their IP addresses and VPN identifiers. An edge router may be allowed to query for external addresses that belong to the same set of VPNs it's in. And a successful query returns the address of the egress optical port that the external destination can be reached through. Main character energy 👑
Here's the catch: IP-optical interface connectivity is limited, so deciding how many lightpaths must be set up and which endpoints they go to are traffic engineering decisions 🫶 Once an initial set of those lightpaths exists, they can be used as adjacencies within VPNs for a VPN-wide routing scheme, for example, OSPF. So the flow goes like this: an edge router first finds the other edge routers it cares about by querying the registry. After it gets the right addresses, an initial overlay lightpath topology may be formed. Then routing adjacencies may be established across those lightpaths, and more routing info may get exchanged to set up VPN-wide routing. It's giving organized 💅
5.3. Signaling-Related
5.3. Signaling-Related
5.3.1. The Role of MPLS
okay so here's a big-brain idea 🧠 wavelengths, and potentially TDM channels inside a wavelength, can be modeled as "labels" 🌈 This concept was proposed in [1], and "generalized" MPLS (GMPLS) mechanisms for making it real are described in [4]. MPLS signaling protocols with traffic engineering extensions, like RSVP-TE, can be properly extended and used for signaling lightpath requests ✨ These protocols can be adapted for client/server signaling in the case of the domain services model, and for end-to-end integrated signaling in the case of the unified services model. Two models, two vibes 💜
5.3.2. Signaling Models
Okay bestie, with the domain-services model, the signaling control planes in the IP and optical networks are completely separate, as shown in Figure 3 below 🦋 This separation also means the IP and optical address spaces are separated too (even though the optical network would be using internal IP addressing). RSVP-TE and LDP can be adapted for UNI signaling, but the full functionality of these protocols will not be used. For example, UNI signaling does not require the specification of explicit routes. On the other hand, based on the service attributes, new objects need to be signaled using these protocols as described in [5, 6]. 🌸
MPLS Signaling UNI Signaling MPLS or other signaling
|
+-----------------------------+ | +-----------------------------+
| IP Network | | | Optical Internetwork |
| +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | | | | | | | | |
| | Router +---+ Router +-----+------+ OXC +---+ OXC | |
| | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ |
+-----------------------------+ | +-----------------------------+
|
|
Completely Separated Addressing and Control Planes
Figure 3: Domain Services Signaling ModelWith the unified services model, the addressing is common in the IP network and the optical internetwork, and their respective signaling control is related, as shown in Figure 4 ✨ It's understood that GMPLS signaling is implemented in the IP and optical domains, using suitably enhanced RSVP-TE or CR-LDP protocols. BUT the semantics of services within the optical internetwork may be different from those in the IP network 👀 For example, the protection services offered in the optical internetwork may be different from the end-to-end protection services offered by the IP network. Bandwidth is another example. While the IP network may offer a continuum of bandwidths, the optical internetwork will offer only discrete bandwidths 🫶 So the signaling attributes and services are defined independently for the IP and optical domains. The routers at the edge of the optical internetwork must therefore identify service boundaries and perform suitable translations in the signaling messages crossing the IP-optical boundary. This may still happen even though the signaling control planes in both networks are GMPLS-based, and even though the control plane is more tightly coupled than in the domain services model. 💅
Service Boundary Service Boundary
| |
IP Layer GMPLS Signaling | Optical Layer GMPLS | IP Layer GMPLS
| |
+--------+ +--------+ | +-------+ +-------+ | +--------+
| | | | | | | | | | | |
| IP LSR +--+ IP LSR +--+--+Optical+--+Optical+-+--+ IP LSR +---
| | | | | | LSR | | LSR | | | |
+-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+
Common Address Space, Service Translation
Figure 4: Unified Services Signaling ModelSo, as Figure 4 shows, signaling in the unified services case is actually multi-layered 🌈 The layering is based on technology and functionality. As an example, the specific adaptations of GMPLS signaling for the SONET layer (whose functionality is transport) are described in [10]. Layers within layers, it's literally a whole thing 🎀
5.4. End-to-End Protection Models
okay picture this 🍓 Suppose an LSP is set up from an ingress IP router to an egress router, going across an ingress IP network, a transit optical internetwork, and an egress IP network. If this LSP is supposed to get protection in the IP layer, how do the IP and optical layers coordinate that service? 🤔
Under this scenario, there are two approaches to end-to-end protection:
5.4.1. Segment-Wise Protection
The protection services in the IP layer could use optical layer protection services for the LSP segment that traverses the optical internetwork. So the end-to-end LSP is treated as a concatenation of three LSP segments from the protection point of view: a segment in the ingress IP network, a segment in the optical internetwork, and a segment in the egress IP network 🧚 The IP layer protection services for an end-to-end LSP must be mapped onto suitable protection services offered by the optical internetwork. Let's say 1+1 protection is offered to LSPs at the IP layer, meaning each protected LSP has a pre-established hot stand-by in a 1+1 or 1:1 configuration. If the primary LSP fails, traffic can be switched to the stand-by immediately ⚡ This type of protection can be realized end-to-end like this. With reference to Figure 5, let an LSP originate at (ingress) router interface A and terminate at (egress) router interface F. Under the first protection option, a primary path for the LSP must be established first. Let this path be as shown in Figure 5, traversing router interface B in the ingress network, optical ports C (ingress) and D (egress), and router interface E in the egress network. Next, 1+1 protection is realized separately in each network by establishing a protection path between points A and B, C and D, and E and F. Furthermore, the segments B-C and D-E must themselves be 1+1 protected, using drop-side protection. For the segment between C and D, the optical internetwork must offer a 1+1 service similar to the one offered in the IP networks 🌸
+----------------+ +------------------+ +---------------+
| | | | | |
A Ingress IP Net B----C Optical Internet D----E Egress IP Net F
| | | | | |
+----------------+ +------------------+ +---------------+
Figure 5: End-to-End Protection Example5.4.2. Single-Layer Protection
okay so this model is way simpler 💖 Here the protection services in the IP layer do not rely on any protection services offered in the optical internetwork. So with reference to Figure 5, two SRLG-disjoint LSPs are set up between A and F ✨ The corresponding segments in the optical internetwork are treated as independent lightpaths in the optical internetwork, and these lightpaths may be unprotected in the optical internetwork. Simple, clean, no drama 🫶
5.4.3. Differences ✨
okay so here's the tea on the two choices 🫖💅 Under the first choice, the optical internetwork is actively involved in end-to-end protection. Under the second choice, any protection service offered in the optical internetwork is not used directly by the client IP network. 🙈
The first choice has some serious perks too. The protection in the optical internetwork may apply collectively to a number of IP LSPs. So with reference to Figure 5, many LSPs may be aggregated into a single lightpath between C and D, and the optical internetwork protection can cover all of them at once. That's giving scalability gains 📈✨ Under the second choice, each IP LSP must be separately protected, which is way more work, bestie 😭
The first choice also lets the IP and optical internetwork run different restoration signaling. Those restoration protocols get "patched up" at the service boundaries so end-to-end protection still works 🧩 Here's the lowkey best part: restoration stays entirely inside the network where the failure happened. That can improve restoration latency, and maybe network stability too, because a fault inside an optical domain gets contained and fixed right there in that domain 🌸 For example, if something breaks in the optical internetwork, the optical network protocols restore the affected internal segments.
Under the second choice, restoration signaling is always end-to-end between IP routers, basically bypassing the optical internetwork 🦋 The result? Restoration latency could be higher. Also, restoration protocols in the IP layer must run transparently over the optical internetwork in overlay mode. Main character energy? Maybe not 💀
BUT (and this is a big but) IP based recovery techniques may be more resource efficient 🍓 It may be possible to send traffic through the redundant capacity under fault-free scenarios. Specifically, it may be possible to use classification, scheduling, and concepts of forwarding equivalence class to route lower class traffic over protect facilities, and then possibly preempt them to make way for high priority traffic when faults occur 👑
6. IP-based Optical Control Plane Issues 🎀
okay now we're getting into the control plane, and it's giving a lot of structure 🧚 Provisioning and restoring lightpaths end-to-end between IP networks needs protocol and signaling support within optical sub-networks, and across the INNI and ENNI. There's a distinction to keep track of here: control procedures within an optical sub-network (Figure 1), between sub-networks, and between networks.
The general guideline in this framework is to separate these cases. Different control procedures are allowed inside different sub-networks, while a common set of procedures is followed across sub-networks and networks. Love that for us 🫶
The control plane procedures within a single vendor sub-network need not be defined, since these can be proprietary 🔒 It is clearly possible to follow the same control procedures inside a sub-network and across sub-networks, but that's simply a recommendation within this framework document, rather than an imperative requirement 💅 So in the following, we'll look at signaling and routing across sub-networks first, and then talk about 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 addressing 📬 What entities should be identifiable from a signaling and routing point of view? How should they be addressed? This section gives some high-level guidelines on this.
Identifiable entities in optical networks include OXCs, optical links, optical channels and sub-channels, Shared Risk Link Groups (SRLGs), and so on 🌈 A big question is how granular the identification should be when it comes to establishing optical trails. The identification scheme must accommodate specifying 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 terminate many optical channels, each of which contain many sub-channels, and so on 🤯
It's perhaps not reasonable to assume that every sub-channel or channel termination, or even every OXC port, could be assigned a unique IP address 🙅♀️ Also, the routing of an optical trail within the network doesn't depend on the precise termination point information. It depends only on the terminating OXC. So finer-grained identification of termination points is only relevant 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 where 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 identifying these termination points directly with IP addresses (with a null selector). The selector can be formatted to have an adequate number of bits and a structure that expresses port, channel, sub-channel, and so on identification 🔢
Within the optical network, establishing trail segments between adjacent OXCs requires identifying the specific port, channel, sub-channel, and so on. 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 thing about 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, 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. Iconic, honestly 👑)
While classifying physical resources into SRLGs is a manual operation, assigning 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. Together 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. Either way, the first step toward network-wide link state determination is discovering 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). That last piece of info is used to specify an appropriate label when signaling for lightpath provisioning 🏷️
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 use the SONET overhead bytes to periodically transmit the (configured) local attributes to the neighbor 💌 So two neighboring switches can automatically determine each other's identities and local connectivity, and also keep track of the up/down status of local links. Neighbor discovery with transparent OXCs is described in [2] 🌟
Here's the mesh network from Figure 6, with its SRLGs 🕸️
+--------------+ +------------+ +------------+
| +-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 🗺️
okay so topology discovery is basically how everyone figures out the topology and resource state of every link in the network 🫶. It can happen inside a link state routing protocol (think OSPF or ISIS), or through the management plane when path computation is centralized 💅. Running the same link state protocol across the whole network, even across sub-network boundaries, means the same protocol runs on the OXCs in every sub-network ✨. If that assumption doesn't hold, then routing between sub-networks has to be interworked, which is giving the inter-network routing vibes from Section 6.7 🦋. So the focus from here on is standardized link state routing 💜.
In general, most of the link state routing stuff still works when you apply it to optical networks 🌈. The way optical links are represented, though, plus some of the link parameters, get changed up a bit in this setting 💀. Specifically:
- The link state information may consist of link bundles [12]. Each link bundle is represented as an abstract link in the network topology 🎀. There are different bundling representations 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 🍓.
- 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 🔥.
- 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 ✨.
- 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 still 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,
- 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,
- 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 😭.
- 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 💜.
- 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 requires 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 ✨
okay bestie, signaling 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 it gets 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. so 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. the vibes are very particular, and I respect it 🦋
6.6.1. Bi-Directional Lightpath Establishment
lightpaths are typically bi-directional 💖 that means the output port an OXC picks 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. at the same time, 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" 💀
when WDM functionality is built into OXCs, a collision also 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. protect the established paths, bestie 👑
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:
- A standard scheme for uniquely identifying lightpath end-points in different networks is required.
- A protocol is required for determining reachability of end-points across networks.
- A standard signaling protocol is required for provisioning lightpaths across networks.
- A standard procedure is required for the restoration of lightpaths across networks.
- 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 the 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 the 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 needs to be explored 🤔
6.7.3. Restoration
local restoration across the ENNI is similar to that across the 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 of 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-layer 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 ✨
okay so dynamic establishment of optical channel trails and lightpaths is quite desirable in IP over optical networks 💖, especially when it's driven by a stable traffic engineering control system, or happens in response to authenticated and authorized requests from clients 🫶.
ngl there are so many proposals suggesting dynamic, data-driven shortcut-lightpath setups in IP over optical networks 🙈. The arguments in them are giving major ATM-in-the-core déjà vu 💀. Deployment of highly dynamic data-driven shortcuts within core networks hasn't been widely adopted by carriers and ISPs, and that's for a few 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 this paradigm won't 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 in the early phases of IP over optical evolution will include the following:
- Dynamic connections for control plane traffic and default path routed data traffic,
- Establishment and re-arrangement of arbitrary virtual topologies over rings and other physical layer topologies.
- 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 around dynamic connection setup in the core center on resource usage at the edge of the optical domain 🎀. One potential issue is the number of flows that an ingress or egress network element can process, either because of aggregate bandwidth limitations or because of a limit on the number of flows (e.g., lightpaths) it can process 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 request, 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, where all nodes maintain a synchronized topology database and advertise topology state information to maintain and refresh that database 🔁. A constraint-based routing entity in each node then uses the information in the topology database, along with 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 with complete knowledge of the physical topology, the available wavelengths, and, where applicable, relevant time domain information 🧠.
A corresponding client will live on each network element that can source or sink a lightpath 📡. The source client would query the server to set up a lightpath from the source to the destination. The server would then check whether such a lightpath can be established based on prevailing conditions. Furthermore, depending on the specifics of the model, the server may either set up the lightpath on behalf of the client, or provide the necessary information to the client or to some other entity so the lightpath can be instantiated 💅.
Centralization helps with 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, though, 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, because 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 this document was written, 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 the underlying optical equipment to 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]. So there are strong motivators to introduce "domains of transparency," where all-optical networking equipment would transport data unfettered by these drawbacks 🧚♀️✨.
So the issue of IP over optical networking in all optical sub-networks, and in sub-networks with limited wavelength conversion capability, deserves special attention 👀. In such networks, transmission impairments from the peculiar characteristics of optical communications complicate 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 also depends 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 resulting optical channel unusable for data communication 😭. The challenge in developing an IP-based control plane for optical networks is to abstract these peculiar characteristics of the optical layer [17] in a generic fashion, so they can be used for path computation 🫶💖.
8. Evolution Path for IP over Optical Architecture ✨
okay so bestie, the architectural models in Section 5 come with a certain amount of implementation complexity 🧠. The overlay model is the least complex for near-term deployment, and the peer model is the most complex 💅. Each model still has its own perks, so that raises the big question: what's the evolution path for IP over optical network architectures? 🦋
The evolution approach this framework recommends is to define capability sets that start with simpler functionality and add more complex functionality later 🌸. Realistically, early 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 is introducing reachability information exchange between the two domains 🔥. That could let lightpaths get set up as part of end-to-end LSP set-up ⭐. The final phase is full support for the peer model, with more sophisticated routing interaction between IP and optical domains 👑.
Using a common signaling framework (based on GMPLS) from the very beginning makes this kind of evolution way easier 🎀. As things evolve, the signaling capability and semantics at the IP-optical boundary get more sophisticated, but the basic structure of signaling stays the same 💖. That means you get incremental developments as the interconnection model matures, instead of having to rebuild all your signaling from scratch 😭.
From a routing point of view, legacy optical networks mostly use Network Management Systems (NMS) for static connection management 🙈. Going forward, connection routing using the control plane will gradually get introduced and integrated into operational infrastructures 🌈. That introduction of routing capabilities can be expected to happen in phases 🧚.
In the first phase, service providers will either upgrade their existing local element management (EMS) software with extra control plane capabilities (and maybe the hardware too), or upgrade the NMS software to bring some automation into each optical subnetwork 💜. So it may be desirable to partition the network into subnetworks, run IGP interoperability within each subnetwork (i.e., at the I-NNI level), and use either static or signaled interoperability between subnetworks 🍓. Basically, the first phase of network level control plane interoperability in IP over Optical networks will be organized around a system of optical subnetworks that are interconnected statically (or dynamically, in a signaled configuration) 🦋. During this phase, an overlay interconnection model is used between the optical network itself and external IP and MPLS routers (as described in Section 5.2.3) 💅.
Moving along this phased approach to IPO routing interoperability evolution, the next level of integration arrives when a single carrier provides dynamic optical routing interoperability between subnetworks and between domains 🔥. 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 be a significant evolution: even if the routing instances stay separate and independent, it would still be possible to dynamically exchange reachability and other types of routing information 😭. Another, more sophisticated step in this phase is introducing dynamic routing at the E-NNI level 👑. That means any neighboring networks (regardless of internal switching capability) would be capable of exchanging routing information with peers across the E-NNI 💖.
Another option is for private networks to skip these intermediate steps and go straight to an integrated routing model from the onset 🌟. This direct evolution strategy is realistic, but it's more likely in operational contexts where both the IP (or MPLS) and optical networks are built at the same time, using equipment from a single source or from multiple closely affiliated sources 🧚. Anyway, because there isn't much operational experience yet in managing this degree of control plane interaction in a heterogeneous network (these issues may exist even when the hardware and software come from the same vendor), an augmented model is likely to be the most viable first option 🙈. Alternatively, a very modular or hierarchical peer model may be contemplated 🌸. There may be other challenges (not just technical, but also administrative and even political ones) that need to be resolved before a full peer model at the routing level is achieved in a multi-technology and multi-vendor environment 💀. Ultimately, the main technical improvement would likely come from efficiencies gained by integrating traffic engineering capabilities into dynamic inter-domain routing environments ✨.
9. Security Considerations 🔐
The architectural framework in this document needs a bunch of different protocol mechanisms to actually work 🎀. Specifically, the roles of neighbor discovery, routing, and signaling protocols were highlighted in earlier sections 🫶. The general security issues that come up with these protocols include:
- The authentication of entities exchanging information (e.g., signaling, routing, or link management) across a control interface 🔑;
- Ensuring the integrity of the information exchanged across the interface 💅;
- Protecting the control mechanisms from intrusions and other modes of outside interference 🛡️.
Because optical connections can carry high volumes of traffic and are generally quite expensive, mechanisms are required to safeguard optical networks against intrusions and unauthorized use of network resources 😭.
On top of the control plane stuff, 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 means the state of the bearer channels carrying user traffic cannot be inferred from the state of the control channels 🙈. Likewise, 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 when designing the relevant control protocols and when operating IPO networks 🧠.
Another issue in IPO networks is that the underlying optical network elements may be invisible to IP client nodes, especially in the overlay model 👀. This means traditional IP tools such as traceroute can't be used by client IP nodes to detect attacks within the optical domain 💀.
For all of the reasons above, the output of the routing protocol security (RPSEC) efforts within the IETF should be considered when designing control protocols for optical networks 🔥.
In Section 2, 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 that 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 intrusions and unauthorized operations can be detected and mitigated 🕵️♀️. For example, with reference to Figure 1, message authentication can stop 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 help counter some forms of denial of service attacks 💪. Replay protection provides a form of partial sequence integrity, and it can be implemented together 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 💼.
Equipment that is not co-located presents increased security threats 😬. In these scenarios, the communicating entities exchanging protocol messages may be connected over an external network 🌐. That 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 these threats, appropriate security mechanisms must be employed to protect the control channels and the 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 🚧. There may also 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 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 used in the control plane of optical networks depend on the specific characteristics of the protocols and the security risks present in a particular operational context 📋. Details about particular operational contexts are beyond the scope of this document, so they aren't considered further here 🙏. Still, it must be stated that such control protocols must take into account the issues associated with separating 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 originating in the optical domain 💔.
10. Summary and Conclusions ✨
okay so bestie, let's wrap this whole thing up 🎀 the goal of this doc was to set up a framework for IP over optical networks, looking at service models plus routing and signaling stuff 🦋 and honestly? there's a whole buffet of choices for IP-optical control interconnection, service models, and protocol mechanisms 🍓 the move here was to support different service models that can level up later, and then define complementary signaling and routing mechanisms so those capabilities actually work 💅
the vibe is evolutionary 🧚 the idea is a common signaling framework (like one based on GMPLS) as the base, and then you can crank up how complex the interworking gets as the requirements get more sophisticated 👑 the key thing: IP-optical control and service interaction starts out based on the domain services model with overlay interconnection, and eventually grows into full peer interaction 🫶 it's giving glow-up arc, no cap 🌈
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 🫶
okay the thank-you list is giving main character credits 🌸 we'd like to thank Zouheir Mansourati (Movaz Networks), Ian Duncan (Nortel Networks), Dimitri Papadimitriou (Alcatel), and Dimitrios Pendarakis (Tellium) for their contributions to this document 💖 and the Security Considerations section got revised with input from Scott Bradner and Steve Bellovin 🙈 iconic behind-the-scenes energy ✨
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.
📦 where this page comes from
- ietf: rfc3717 2004-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms