Archive 25 April 2007 #59
ETHERNET AS A CARRIER OPTION:
ANOTHER WAY TO FORWARD PACKETS
Or, What's a Packet To Do?
by William Flanagan, Publisher
So these two packets walk into a node and ask, "Where do we go from here?" The gimlet-eyed node scans their headers, consults the guest list, and tells them. OK, I can't get a laugh out of packet forwarding, but the joke often is on all of us because there are so many formats and names that it's sometimes not clear what's happening in the transmission network.
Lack of clarity admits confusion, allows hype to thrive, and probably misleads some network operators. This ViewsLetter draws out similarities among major packet networks--X.25, IP, Frame Relay, ATM, MPLS, and now Ethernet in the MAN/WAN--and clarifies some key concepts.
A packet is a finite amount of user data (the payload) associated with some administrative information in one or more headers (and possibly a trailer), see part A of the drawing.
The header necessarily contains the packet's destination address (DA). That's what the node looks up in the guest list, a/k/a the forwarding table, routing table, etc. Other fields vary. Some DAs are large enough to be globally unique so they don't change (X.25, IP, Ethernet); others are short, have only local significance, and may be changed by the node (FR, ATM, MPLS).
The essential decision per packet in each node is "Where next?" Typically the next stop is an outbound port queue on that node. Some addresses may invoke manipulations such as a change in address or specific handling.
Regardless of the transmission technology, the string of forwarding instructions in a series of nodes between the end points defines a connection (see highlighted entries in part B of the drawing). In some networks (FR, ATM) the virtual circuit (VC) concept is quite clear. In others (IP, MPLS) the same principle applies but nobody admits it--unless you're using the "traffic engineering" (TE) version.
A VC implies that the connection must be set up before the first packet is sent. This is the case for FR and ATM permanent VCs, MPLS label switched paths, and PBT tunnels. Datagram service like IP, which accepts packets before the connection is set up, assume the network can figure out the path from existing entries in the forwarding tables or can find a path with a routing protocol. The packet forwarding is much the same.
For example, MPLS forwards packets in exactly the same way as frame relay. The difference between the technologies lies in how the entries (labels or data link connection identifiers, DLCIs) get into the forwarding tables.
-- In FR, the network manager defines the VC by inserting the DLCIs into each node--usually via management software that calculates paths and capacities independently of the nodes and in a proprietary way.
-- MPLS nodes distribute labels along the paths chosen by a routing protocol like BGP or OSPF. These are the same paths taken by IP packets unless (for TE) the network management system takes over the choice of path and sets the label values in the nodes.
Sound more than vaguely similar? Well, here it comes again:
-- Provider Backbone Transport (PBT) is based on Ethernet addresses set by management in forwarding tables of switches.
-- X.25 and ATM define standard interfaces to the network. Internally, the nodes set up essentially the same connections, usually based on proprietary methods chosen by the switch maker.
Note that all these transmission methods operate at Layer 2, the Link layer, of the OSI protocol model. IP is a Layer 3 protocol, but the forwarding decisions are not much different. At any given moment, for each type of traffic there is one path through the IP network defined from one end point to another by entries in the routing tables--until there is a change in the network . (The path may be split for load balancing, but think of many threads in one rope.) Sounds very much like a VC, but it's set by the routing protocol automatically and is not under the control of a centralized management system--unless you count source routing.
There's much debate over the relative merits of these transmission technologies, but from the viewpoint of finding a path for packet forwarding they fall into three categories:
1. Automatic path finding by the nodes (IP, X.25, basic MPLS)
2. Paths assigned by a management function (FR, ATM, MPLS-TE)
3. Source routing based on the originating host's knowledge of the network
For a carrier, source routing would require revealing to customers too much information about the core network. The real choice is between 1 and 2. Traditionalists among carriers tend to be comfortable with assigned paths, a lot like circuit engineering. They offer control over bandwidth utilization, allow alternate paths for quick recovery, etc. Telco folks like Layer 2 technologies. Internet folks tend toward automatic routing on IP. Sometimes they seem to assume that bandwidth is free and unlimited (not far off from what fiber has brought us).
One of the ironic aspects of the technology debate is that two key formats, MPLS and PBT, never reach the customer site. Should it matter to the customer what happens to his bits after they enter a carrier network? We contend that the performance and functional specifications at the user-network interface (UNI) are all that count.
Where does that leave PBT? In a pretty good position.
-- Carriers get the path control they like (with OA&M functions) from an understandable technology at the cost of some additional bandwidth (now almost free) for the larger Ethernet header on each packet.
-- Customers get a standard Ethernet UNI, quick alternate routing, and low latency.
We might calls these the "virtues of virtual circuits."
NEXT TIME: A View down a tunnel--what it is and how it helps.
How Can Flanagan Consulting Help You?
We understand not only the technology of network architectures
but also the surrounding business processes: procurement, bid
preparation/analysis, statements of work, financial analysis,
consensus building, and more.
"Flanagan Consulting" and "ViewsLetter" are Service Marks of W. A. Flanagan, Inc.
W. A. Flanagan, Inc.
45472 Holiday Drive, #3
Sterling, VA 20166
|In Converged Networking,
We have the Experience