By Thomas Rasmussen
OVERVIEW
Packet optical transport networks are a sound approach for meeting future traffic requirements. The choices made in designing platforms for these networks depend on several factors.
The future network architecture of metro-aggregation transport is under serious consideration among network operators, and many different approaches have been suggested. The overall desire is to migrate from existing SONET/SDH legacy networks to some kind of packet optical transport network (P-OTN) that can deliver lower cost per bit transported and provide the same resilience as legacy networks.
This article will describe the key elements of a P-OTN platform and why such systems have a good chance of becoming the preferred approach. Also, various P-OTN equipment architectures such as switch fabric-based, optical data unit crossconnect-based, and ROADM-based systems will be reviewed and compared.
What is P-OTN?
The term P-OTN is only a few years old and the definition is still not completely frozen. However, two key elements compose the central parts of a P-OTN network element:
- ITU-T G.709 OTN support
- Connection-oriented packet transport support such as MPLS-TP/PBB-TE/T-MPLS (and possibly VLAN/PBB)
Also, P-OTN equipment will almost by nature support WDM. P-OTN equipment will typically offer transport of a very wide range of client signals. Ethernet clients dominate today, but legacy SONET/SDH plus storage area network as well as video are among other client-type signals.
An important element of OTN is the so-called subwavelength level -- the optical data unit (ODU) -- which provides connectivity at a finer granularity than per-wavelength. For example, a 10-Gbps optical wavelength may carry four electrical ODU1s at 2.5 Gbps each.
Why is P-OTN important?
It is believed that the metro part of the network is where P-OTN will be used in the near future -- that is, in the aggregation/distribution network between the access nodes that connect end users (such as DSLAMs) and the server nodes at the edge of the core network.
Generally, the metro network does not need to know about the actual services (content) of the user traffic. However, the metro network must enable the carrier to quickly and cost-effectively change connectivity and bandwidth in the network. For instance, if a big company moves from one location (access point) to another inside the metro network, the network would have to be reconfigured to adapt to the new bandwidth use.
Traditionally, SONET/SDH has been the preferred transport technology in the metro network. This made sense since most of the access connections from homes and enterprises as well as from mobile networks used SONET/SDH or PDH interfaces that fitted directly into SONET/SDH. Also, a carrier could easily provision and monitor its network from a central network management system (NMS) that fully supported SONET/SDH.
Since OTN is designed to carry any type of traffic transparently it would seem the optimum transport container to replace SONET/SDH. When packet data are sidelined with SONET/SDH as a client in the OTN network it is obvious from the basic metro network requirements that a path-provisioning mechanism and operations, administration, and maintenance (OAM) methodology need to be added -- i.e., connection-oriented packet transport.
P-OTN network element architectures
Even though P-OTN is a good choice for the metro network, it is not obvious what its network elements should look like. How to make the core of the P-OTN network element is an important question that requires a look at the basic functions a P-OTN node core can perform and how these basic functions can be implemented.
FIGURE 1. A high-level block diagram of P-OTN nodes based on a) optical core, b) OTN core, and c) packet core.
As shown in Fig. 1 the core can have three different basic functions:
- optical core
- OTN core
- packet core
In a given network it is likely most cost effective to support combinations of the three. But let us first describe them individually.
Optical core. The function of the optical core is to connect traffic at the wavelength level. An optical core can be implemented by fiber patch panels, fixed optical add/drop multiplexers (OADMs), or reconfigurable OADMs (ROADMs). The first two allow static allocation of wavelengths, whereas a ROADM enables dynamic allocation.
An optical core should enable very efficient allocation of large chunks of bandwidth for a specific network element without the need for optical-to-electrical conversion. An optical core will almost always be used in conjunction with either an OTN core and/or a packet core but could also be used for simple point-to-point connection.
OTN core. The function of an OTN core is to connect traffic at the subwavelength level (ODU level). So traffic on an incoming wavelength is demultiplexed to some lower-level ODU container. Client traffic is also mapped to the same ODU level and thereby connectivity between any line- or client-side ODU to any other client- or line-side ODU can be obtained as illustrated in Fig. 1.
The OTN core can be implemented in a number of ways. One approach would be to implement an ODU crossconnect very similar to the traditional crossconnect that is the central part of most SONET/SDH ADMs. Another way would be to implement a cell-based fabric switch. In this implementation, all OTN traffic is converted to fixed-length packet cells with an equipment-internal header address by a segmentation assembly/reassembly (SAR) function. The cell headers identify the ODU port numbers in the OTN core; these headers are thus used by the central packet switch to forward the cells to the right OTN core ports.
Packet core. The function of a packet core is to connect traffic based on Ethernet/MPLS addresses/labels among a number of internal “packet ports” (for instance, Ethernet, SPI-4.2, or Interlaken). So a P-OTN node based on a packet core must extract the packet flows from the incoming wavelengths and aggregate the traffic to these internal packet ports.
A packet core is implemented by a cell-based packet switch for forwarding user traffic. All incoming traffic is converted to fixed-length packet cells with an equipment-internal header address by a SAR function. The cell headers are used to identify individual packet ports and the cell header is used by the central packet switch to forward the flows to the right packet ports.
The optical core is almost always present in some form since it is typically the most cost-effective way to pass through traffic that is not intended for a specific node at the optical level. Therefore, it is really the packet core and OTN core that are the new architectural elements for P-OTN nodes. When comparing the two, a packet core can obtain much finer granularity -- down to the individual customer flow leve -- than an OTN core can. In contrast, the OTN core is much simpler to implement and manage.
So, the choice of core function depends on the granularity and need for managing individual customer flows in a P-OTN node. If, for instance, the P-OTN node's function is to act as an ADM for multiple Gigabit Ethernet (GbE) ports into OTN transparently and without the need to manage individual customer flows within each GbE link, an OTN core should be chosen. On the other hand, if the function of the P-OTN node is to classify the individual flows from GbE ports on many input cards and map different types of traffic (VoIP, IPTV, best-effort traffic, for instance) into different ODU containers, a packet core is required.
Finally, it is worth mentioning that the choice of packet or OTN core can be based on legacy deployments. If a metro network based on nodes with packet cores already exists and the network operator wants to add OTN and TDM support, it is natural to keep the packet core of the equipment.
Using connection-oriented packet transport
The other important part of a P-OTN node is connection-oriented packet transport. The usual manner in which a packet finds its way through a network is either via routing or switching. In either case, there is no guarantee of the exact path that packets belonging to the same communication flow will take through a network. This makes it difficult to control the quality of the connection.
The idea behind connection-oriented packet transport is to create a way of transporting packets that has the same elements of deterministically provisioned paths and overhead bytes for OAM as SONET/SDH. In a connection-oriented packet transport network, the routing and switching are disabled in the network elements and the forwarding of packets is done based on information configured by the NMS or a control plane. Also, a special type of control packet (OAM packets) is transported along with the regular data packets to monitor the path between the two endpoints.
Connection-oriented packet transport comes in different flavors:
- MPLS-TP, which is under standardization by ITU-T and IETF and is based on Multiprotocol Label Switching (MPLS) labels for the forwarding of packets. MPLS-TP (“TP” for “Transport Profile”) is a revision of the T-MPLS specifications previously standardized by ITU-T
- PBB-TE, which is under standardization by IEEE PBB-TE is based on Ethernet addresses for the forwarding of packets, but forwarding tables are configured rather than being autonomously updated by address-learning processes in the products
Figure 2 shows a simple drawing of how customer traffic can be deterministically set up by means of MPLS-TP label-switched paths (LSPs) with both a working and a protection path through the network. Each P-OTN node includes an MPLS-TP function that acts either as an endpoint switch or as pass-through. The endpoint function is where customer Ethernet flows are associated with a protection and working LSP. The pass-through function is just forwarding data based on a preconfigured MPLS forwarding table.
FIGURE 2. A network of three P-OTN nodes. A, B, C are different customer flows that are transported via protected LSPs over the OTN network. Solid lines show working LSPs and dashed lines shows protection LSPs.
MPLS OAM connectivity verification (CV) packets are repeatedly transmitted on the working and protection LSPs. If three of these CV messages fail to arrive on the working LSP, the equipment will automatically switch both ends to the protection LSP and the traffic flow for that LSP can thereby be restored within less than 50 msec. This type of protection is very similar to the protection schemes used in SONET/SDH networks.
Wrap up
This article has summarized the key elements of a P-OTN network node and described some of the basic functional design options that must be taken into account: Should the P-OTN nodes provide connectivity at the wavelength, subwavelength (ODU), or packet-flow level?
The answer depends on what functions the P-OTN node should perform in the network. If the P-OTN nodes are purely transport nodes, a combination of wavelength and subwavelength connectivity is the best option. Packet-flow connectivity is required if the P-OTN node needs to perform traffic management and forwarding based on customer traffic flows. In the latter case, Fig. 2 showed what a P-OTN network with MPLS-TP connectivity could look like.
Thomas Rasmussen is vice president, product line management, at TPACK.
LINKS TO MORE INFORMATION
Lightwave Online: Verizon Wants Packet Optical Transport for Long Haul
Lightwave Online:Multipoint PBB-TE and T-MPLS
Lightwave Online: Nortel Shifts MEN Focus to Packet Optical Transport