Spamming, NAT, Switching and Labels - Page 2

 By Pete Loshin
Page 2 of 2   |  Back to Page 1
Print Article

Switching and Labels

IP and ATM are two dissimilar protocols that solve roughly the same problem: linking nodes on sometimes very large networks. IP focuses on routing, operates at the network layer rather than the link layer, and can be said to use relatively dumb devices to make the network itself "smart." ATM, on the other hand, focuses on switching, operates at the link layer, and uses "smart" devices that switch data across dumb networks. Both have advantages, with IP having the edge in terms of reliability and robustness, while ATM tends to be faster.

The Multiprotocol Label Switching (MPLS) architecture makes it possible for ATM and other non-broadcast, multiple access (NBMA) network protocols that rely on virtual point-to-point circuits, like Frame Relay, to move IP traffic. Under MPLS, devices on the edge of the NBMA network assign inbound IP packets a Forwarding Equivalence Class (FEC) based on their destination addresses. This FEC is encoded as a "label," which is used by switches in the network to make decisions about where to send the packet.

Each switch looks up the incoming packet's label on a switching table to determine where the packet should be sent and what new label to give it. This process allows very fine control over how packets are handled within the MPLS network: The decision about how to treat the packet is made at the ingress point, and once inside, the packet is switched appropriately. MPLS permits the ingress switch to use any information about that packet to make this decision, so Quality of Service (QoS) issues can be brought to bear, allowing some packets from the same source and going to the same destination to be given different switched paths through the network.

The MPLS and related RFCs published in January constitute the core specifications for MPLS, including the MPLS architecture (RFC 3031), the Label Distribution Protocol or LDP (RFC 3036), and use of MPLS on ATM (RFC 3035) and Frame Relay (RFC 3034).

Although some of these documents were approved for publication well over a year ago, they could not be published as RFCs until all normative references (references to aspects of the specification documented elsewhere that define the Proposed Standard) were published as permanent documents. Until all the related (and temporary) Internet-drafts were published as RFCs, none of them could be published as RFCs.

With MPLS, network engineers are finding new ways to maximize the benefits of ATM and Frame Relay to speed IP data across the Internet. The publication of these RFCs firmly places MPLS and LDP on the standards track.

What's Next

Some interesting new RFCs came out in January, but February looks to be even: A flurry of new RFCs, document and protocol actions, and four new working group approvals came in during the first couple days of the month. Check back in a couple of weeks for the latest about IETF working groups (a few old ones have closed, but as many as a dozen new ones are open for business or in the pipeline), as well as other developments; we'll cover February's RFCs in the first week of March.

And, if you haven't made your reservations for IETF 50 in Minneapolis (March 18-23) yet, you'd better do it soon. //

Pete Loshin has been writing about IP networking since 1988, including 20 books about networking, the Internet, and Internet standards. The founder of Internet-Standard.com, Pete frequently consults on Internet protocol issues.

This article was originally published on Feb 8, 2001
Get the Latest Scoop with Networking Update Newsletter