[ Team LiB ]
[ Team LiB ]
2.7 IP-Centric Control of Optical Networks
We have already seen the importance of IP as the dominant type of traffic, and how this leads to new transport techniques such as 10 GbE and GFP for SONET. These are ways in which IP has influenced the data plane. But another significant influence on transport networking has been the transfer and extension of ideas and techniques used for topology discovery, routing, and virtual circuit establishment by the Internet control plane. This section is devoted to an overview of the key concepts and techniques through which an optical transport network may be managed and controlled through adaptations of IP-network routing protocols. The overall approach is usually referred to as "IP-centric control" of the transport network [BeYa00]. In [Gers00], Gerstel compliments that article with an interesting discussion of just what combination of pure Internet-style signaling and centralized network management to use. Also recommended for background in this area is [McBo98].
Transport networks have traditionally been centrally controlled in terms of provisioning (and taking down) service paths as needed.
Transport path requirements grew or changed relatively slowly and centralized, even semi-manual, operations control was adequate. In contrast the circuit-switched voice network handles major changes in terms of its internal circuit configuration every minute and has therefore been highly automated in its call by call circuit establishment and tear-down functions. Although under overall supervisory monitoring by network management, individual call routing evolved to become a highly distributed and adaptive decision making process handled among the switching nodes themselves.
One view of the future in transport networking is that high-end applications and major source/sinks of packet flows such as router nodes will "dial up" lightwave paths on demand and release them again, perhaps only minutes later. It is at least debatable, given that a lightpath supports 10 to 40 Gb/s, when the transport network would see lightpath demand that is truly as random in its arrival and departure times as connections in the voice switched network. It seems more practical and likely that lightpath requirements would often be amenable to some form of scheduling or advance notification of the upcoming lightpath requirements. More frequent random changes can be expected from applications and client networks that generate requests for STS-1, STS-3, GbE levels of connection or capacity augmentation. As with the airlines, there is always a discount for customers that pre-announce their plans. The truly random arrival pays the most. In addition, scheduling or batch forecasting is plausible because the optical layer path requirements have primarily only to respond to the changes in the aggregations of such lower rate service connections. Nonetheless, whatever characteristic time scale is envisaged for changes in the OTN connection state the question becomes: How can the OTN autonomously establish and take down requested lightpaths within itself, efficiently, and on an ongoing basis, driven only by the "user" demands, without centralized control on a call by call basis?
The vision of a transport network operating in this "self-organizing" way, using simple interaction between cross-connect nodes to establish and remove service paths as needed, was researched in the context of SONET-based mesh networks in [Grov89, MacG91, Grov97]. The approach then used for distributed nodal signaling interaction was, however, an extension of K1-K2 state byte signaling methods used for restoration path finding in a mesh network. Today a more general and expandable paradigm for distributed cooperation between nodes is provided by explicit topology discovery and routing protocols used on the Internet. Note that using extensions of these widely known protocols for control of an optical network should not be confused with meaning that all transport is also by IP routing. In other words, it is the control plane of a transport network that we consider here, not the data plane.
[ Team LiB ]
[ Team LiB ]
2.8 Basic Internet Protocols
The needed background is an overview of the key protocols for Internet routing and how these are extended for dynamic provisioning in an OTN. In later chapters this material will help readers appreciate some of the options for implementation of mesh-based survivability, in particular how IP-centric protocols can be the basis for setting up certain types of path protection arrangements, how MPLS layer restoration with oversubscription works, and the feasibility of various types of networks that are self-planning against failures based on global topology knowledge. To avoid confusion in what follows, note that in the suite of basic Internet protocols, the view of the network is purely topological. A "link" either exists or does not between two nodes. Its capacity is not described or resolved although it may have an associated routing cost. This is of course quite different from the transport network view where every span has a specific capacity that must be taken into account in routing, etc. It is in the extension of the basic IP protocols that a capacitated view of network resources becomes available for use in transport network applications. For more through treatments of the basic Internet Protocols see [Moy98], [Huit95],[Stev94], [Perl92].
2.8.1 TCP
TCP stands for transmission control protocol. It is the basic protocol to create and manage logical connection-oriented services over a connectionless IP routing layer. TCP provides a reliable stream delivery and virtual connection service to applications through the use of sequenced acknowledgment with retransmission of packets when necessary. TCP uses a windowed transmission protocol and slow-start fall back when it encounters errors or congestion, to try to manage connection throughput. TCP also multiplexes many applications between hosts or clients by managing port numbers that label each TCP/IP packet to maintain separate associations between different communicating process pairs between the same two computers.
2.8.2 OSPF
Open Shortest Path First (OSPF) is a routing protocol used to determine "least cost" routes for packets within IP networks. The cost criterion is an arbitrary link weight that administrators associate with each link adjacent to OSPF nodes. OSPF is a fundamental protocol to the Internet and to IP-centric lightpath routing because as part of its operation it discovers the entire network topology. The basic sequence of operations performed by OSPF routers is:
Discovering OSPF neighbors Forming logical routing adjacencies Synchronizing databases
Calculating the routing table Advertising Link States
Routers will go through these steps when they first come up, and will repeat these steps in response to events that occur in the network.
A router must perform these steps for each subnetwork it is connected to, except that it generates and maintains a single integrated routing table even if connected to several networks. A router employs the following subsidiary protocols and processes for its overall implementation of OSPF.
"Hello" Protocol
Every ten seconds (nominally, but this can be changed) a router sends a hello packet to each immediately connected (logically not physically) adjacent router on each link that is in operation on one of its ports. As long as the adjacent router answers, the link is considered in an "up" state. If four "hello" packets are sent without an acknowledgment, the link is determined to be in a "down" state.