RFC 2340

Nortel's Virtual Network Switching (VNS) Overview

📅 published May 1998, from ietf

Title Block 🎀

Okay bestie, first the paperwork so you know exactly what we're looking at ✨ This is RFC 2340, titled Nortel's Virtual Network Switching (VNS) Overview. It was written by B. Jamoussi, D. Jamieson, D. Williston, and S. Gabe, all from Nortel (Northern Telecom) Ltd., and it came out in May 1998. It's marked as Informational, so it's sharing info, not setting a standard 🧚. The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Status of this Memo 📋

Quick disclaimer: this memo is here to give info to the Internet community 💜 It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌸

The copyright belongs to the Internet Society, and the line reads Copyright (C) The Internet Society (1998). All Rights Reserved. 🦋

Abstract 🌈

So the abstract is basically the whole pitch 💅 VNS is a multi-protocol switching architecture, and it does a LOT. It gives you COS-sensitive packet switching ⭐ It makes operating protocols like PPP and frame relay way less complicated 🙈 It sets up logical networks and keeps traffic separated for Virtual Private Networks (VPNs) 🎀 It handles security and traffic engineering 🔥 It makes WAN broadcasting and multicasting efficient 🦋 And it cuts down on the address space you need 💖 Also, VNS reduces the number of routing hops over the WAN by switching packets based on labels. Main character behavior, honestly 👑

VNS has been proven in production networks for several years 🫶

Table of Contents 🍓

1       Introduction ............................................   2
2       What is VNS? ............................................   3
3       VNS Header  .............................................   5
4       VNS Label Distribution ..................................   7
5     Logical Networks (LNs) ....................................   7
6       VNS Routing .............................................   8
7       VNS Forwarding ..........................................   9
   7.1   Unicast ................................................   9
   7.2   Multicast ..............................................   9
8       Traffic Engineering .....................................  10

   8.1   Equal Cost Multipaths ..................................  10
   8.2   Trunk Load Spreading ...................................  10
9       Class of Service ........................................  11
10      VNS Migration Strategies ................................  11
11      Summary .................................................  11
12      Security Considerations .................................  12
13      Acknowledgments .........................................  12
14      Authors' Addresses ......................................  13
15      Full Copyright Statement ................................  14

1. Introduction ✨

Okay so the wide area backbones that carry LAN traffic have some real problems right now 😭 There are five big ones: scalability, service differentiation, redundancy, administration, and traffic containment.

First, scalability is becoming a huge deal 📈 Bandwidth demand and geographic reach are growing super fast, and as the WAN gets bigger, traditional point-to-point and NBMA topologies or network models start losing their performance 💀

Second, we really need several Classes of Service (CoS) now 🎀 The days of one single "best effort" service are over, and service providers want to be able to tell their clients apart based on several policies 💅

Third, the WAN often carries mission-critical traffic, and losing service is a no-go 🙅‍♀️ Path redundancy has been handled inefficiently so far, since it means adding extra links or VCs 🫠

Fourth, network operators want admin to be easy and simple 🧚 Big NBMA topologies need a lot of PVC provisioning until SVC deployment becomes more ubiquitous. With point-to-point models, IP address space can get used inefficiently, and you end up needing non-trivial network schemas just to hold reserved address space 😩

Finally, proper traffic segregation is becoming an absolute must 🔒 Right now people handle this by adding leased lines or VCs, which separate traffic flows based on region, interest, or protocol 🙈

Nortel's Virtual Network Switching (VNS) is a technology that solves these challenges efficiently 🦋

So here's the roadmap ✨ Section 2 gives you an overview of VNS. The VNS header is specified in Section 3. Section 4 describes the VNS label distribution mechanism. Section 5 defines how a VNS network can be partitioned into Logical Networks (LN). Section 6 outlines VNS routing. Section 7 defines both unicast and multicast forwarding. Section 8 describes the mechanisms used to engineer the traffic. Section 9 defines the COS based switching of VNS. Section 10 provides network migration scenarios using VNS. And a summary of VNS is provided in Section 11 🌸

2. What is VNS? 💖

Virtual Network Switching (VNS) is a CoS-sensitive multi-protocol label switching architecture 👑 It reduces or eliminates the number of layer 3 hops over the WAN by switching traffic based on labels.

VNS makes a network of point-to-point links look like one single LAN (broadcast, multiple access) media 🧚 The network used by a particular instance of VNS is called a Logical Network (LN), which gets a closer look in Section 5.

Now, about the ISO Network Layering Model 🍓 The Data Link Layer gets expanded to include the VNS network layer. From the ISO Network Layer's point of view (for example, IP), VNS is treated as a Data Link Layer 💅

        ------------------------
        | Application          |
        ------------------------
        | Presentation         |
        ------------------------
        | Session              |
        ------------------------
        | Transport            |
        ------------------------      -------------------------
        | Network (e.g., IP)   |     / Network VNS            |
        -----------------------------                         |
        | Data Link                 |--------------------------
        -----------------------------                         |
        | Physical             |     \ data link (e.g., ATM)  |
        ------------------------      -------------------------

            Figure 1. ISO Network Layering Model for VNS

In a VNS Network there are three separate nodal functions 🌈 You've got an ingress node, an egress node, and a tandem node. The ingress and egress nodes are the boundary between an IP network and the VNS network, so these nodes run both IP routing and VNS routing 🔥 Tandem nodes only need to run VNS routing 🫶

A LAN packet gets encapsulated in a VNS header as it enters the LN 📦 The label in the header is what switches the packet across the LN. The encapsulation header holds the identifier of the last node (the egress node) that processes the packet as it moves through the LN 🦋 The first node (the ingress node) is the one that decides which egress node the packet goes to ✨ Every node between ingress and egress (the tandem nodes) independently picks the best forwarding route to the egress node named in the packet 💜

Network layer protocols see VNS as a shared broadcast media, where the speed to reach any node is the same for all nodes 🌸 VNS makes sure traffic for other nodes gets forwarded optimally. This transparent view means all the details of the network (for example, topology and link states) can be hidden from the Upper Layer Protocols (e.g. Layer 3 routing protocols) and their applications 🙈 VNS also makes sure that changes to topology and link state stay hidden too 🎀

The network layer protocol on the ingress node sees the network layer protocol on the egress node as its logical, directly connected neighbor 🧚 This is a big deal, because network layer protocols always decide which directly connected neighbor should get a forwarded packet ⭐ The actual topology under the connectionless network is managed entirely by Virtual Network Switching and hidden from the network layer protocols 💖 To the network layer, VNS just looks like another Data Link Layer (or media), even though VNS is a network layer running on top of the real Data Link Layer (for example, ATM trunks) 🫠

For the ingress node to pick the egress node that gives the best path to the packet's final destination, it needs to know two things 💅

  • the nodes that can be reached in the network
  • the topology of the network that is using the VNS services for transport across the network (but not necessarily the topology of the full network)

That knowledge comes from network layer routing mechanisms like IP's Open Shortest Path First (OSPF) and Address Resolution Protocol (ARP) 🌈

Once the network layer protocol on the ingress node has decided which neighbor to send the packet to, VNS forwarding (a part of VNS) is responsible for delivering the packet to that node 🔥 When the packet reaches the egress node, it gets handed to the network layer protocol, which forwards it to its ultimate destination 🦋

Last but not least, tandem nodes don't interact with the network layer protocols at all 🙈 They only need to know the VNS network topology. They make their forwarding decisions using the egress node identifier and LN identifier carried in the VNS header of the packet 👑

Part 1 of 3 done, bestie! 🌈💖

3. VNS Header ✨

Okay bestie, VNS has two header looks 🎀: a unicast one (Figure 2) and a multicast one (Figure 3). Here's the unicast fit:

       3                   2                   1                   0
     1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      TTL      |      LNN            |x|LS-Key |x|DP | CmnHdr  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Protocol Type |         Destination Node Identifier           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  COS  |x x x x|         Source Node Identifier                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Network Layer Header (e.g. IP)                |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Data                                 |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2. Unicast VNS Header

The unicast header has these fields, and each one has a job:

  • Common Header (CmnHdr): this is how the packet says "hey, I'm a VNS encapsulated packet" 📦
  • Discard Priority (DP): tells you the congestion level at which the packet can get dropped 🗑️. The value gets set on the originating node based on policy info (see Section 9).
  • Load Spreading Key (LS-Key): says which stream the packet belongs to, for equal cost multipath and trunk load spreading (see Section 8) 🌊
  • LNN: the Logical Network Number, which tells you which logical network the packet belongs to. It's used together with the destination node identifier as the VNS switching label (see Section 5) 🏷️
  • TTL: the Time To Live field. It helps catch and toss packets that get stuck in temporary routing loops 🔄
  • Destination Node Identifier: an ID that uniquely identifies the destination node. It's unique to the whole physical network, not just the LN, and paired with the LNN it forms a global VNS switching label 🎯
  • Protocol Type: says what kind of Network layer protocol is riding in the packet, like IP, IPX, or Bridging. If the packet is a multicast one, that gets flagged in this field too 🧩
  • Source Node Identifier: an ID that uniquely identifies the source node (the ingress node) 🚪
  • CoS: the Class of Service field, which gives the routing class of service. It also affects the packet's Emission Priority in the scheduler (see Section 9) 💅
  • Reserved Fields: every field marked with "x" is Reserved 🤫

And here's the multicast look 🦋:

       3                   2                   1                   0
     1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      TTL      |      LNN            |x|LS-Key |x|DP | CmnHdr  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | PT = Multicast|         Destination Node Identifier           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  COS  |x x x x|         Source Node Identifier                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Protocol Type |x x x x x x x x|    Multicast Group            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Network Layer Header (e.g. IP)                |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                          Data                                 /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 3. Multicast VNS Header

The multicast header in Figure 3 has all the fields of the unicast header 🫶. On top of that, it adds:

  • Multicast Group: identifies a sub-group within the logical network that receives the multicast packets 📣
  • Protocol Type: says what kind of Network layer protocol is in the packet, like IP, IPX, or Bridging 🧩

4. VNS Label Distribution 🏷️

Label distribution in VNS is a distributed, serverless, topology driven approach, so no central label boss needed 👑. Standard ARP or address gleaning is used to distribute and map network layer addresses to VNS addresses.

A VNS Label is a 6 byte encoding of the LNN and the node ID. VNS Labels get treated as MAC addresses by the network layer, which means labels are distributed the same way network layers already distribute MAC addresses. VNS borrows existing L2/L3 mapping techniques, so it doesn't need a separate Label Distribution Protocol. Lowkey genius 🧠✨

5. Logical Networks (LNs) 🌐

A logical network is a subset of the nodes in a network, plus a subset of the trunking facilities that link those nodes. Logical networks split the network into subnetworks, and each one serves a piece of the overall topology 🍰.

Every logical network supported on a given node has its own routing and forwarding table (built by VNS). So routing decisions are based on the resources available to that logical network, not the whole network 🎯.

Each VNS instance discovers all the trunks connected to neighbors that support a matching LNN. This is a HUGE admin saving 😭, because VNS provisioning happens per node, not per link. You only need a unique node ID and an LNN. Figuring out which trunks support which LNNs happens at run time, so there's less manual work and the LN can adapt to topology changes on its own 🦋.

Multiple Logical Networks bring these perks to the network system:

  • Logical networks let service providers serve multiple private networks (or Virtual Private Internets) easily over one network 🏢
  • Logical networks can limit how much one network layer protocol affects the others. This matters a lot for protocols that broadcast or multicast a big chunk of their control or data packets. It boosts the effective bandwidth of the trunks and helps the overall network scale better 📈
  • Logical networks let you configure the network around individual communities of interest and geographical subnetworking needs 🗺️
  • Routing control traffic only matters in the local subnetwork, and stays isolated to that subnetwork 🤐
  • Logical networks let different instances of the same protocol share trunk facilities 🤝

6. VNS Routing 🛣️

VNS routing is a link state routing system that uses a lot of the same concepts as OSPF and PNNI. Its biggest twist is that it can calculate shortest path trees for routing unicast traffic, and spanning trees for routing multicast traffic, within a Logical Network 🌳.

VNS routing supports only one type of interface, called a VNS link. A link is a set of trunks that join two VNS neighbor nodes. Each node in a VNS network keeps info about the state of its locally attached links. Whenever there's a significant change to a link's state or attributes (like up/down, speed change, or available bandwidth change), that info gets flooded throughout the network 🌊.

Each node stores and forwards the link state info it receives from all the other nodes. That way, every node has the same view of all the nodes in the network, along with all their link state info 👀. This data is used to compute both the shortest path to reach each node in the Logical Network and a spanning tree for the Logical Network.

Logical networks aren't tied to a particular trunk or link. They get configured on a node. By default, a link supports a specific logical network if both nodes it connects are configured to support that logical network number. This saves a ton of operational effort, since you don't have to configure logical networks on every link or trunk 💅.

When a link first comes into service, a protocol runs so the two neighboring nodes can exchange info about the logical networks they support. That lets both nodes figure out whether the link should count as a locally attached link for a logical network 🤝.

7. VNS Forwarding 📬

VNS supports two types of forwarding: unicasting and multicasting. With unicasting, the data packet arrives at the ingress node and gets forwarded to a single destination (the egress node) 🎯. With multicasting, the data packet arrives at the ingress node and gets forwarded to all the other nodes in the logical network 📣.

7.1 Unicast 🌸

When a packet first enters the LAN internetwork, the network layer routing protocol figures out the next hop on the best route for the packet to reach its final destination. If the best route goes through a VNS Logical Network, the network layer routing protocol relies on VNS forwarding to get the packet to the egress node 🚚. A VNS packet header containing the node ID (the unique ID assigned to each node) of the egress node gets added to the front of the packet, and VNS forwarding is invoked to deliver it. The network layer routing protocol learns the egress node ID through Address Resolution Protocol (ARP) for IP, and through Source Address learning for bridging 🔍.

As the packet traverses the LN, routing decisions get made to determine the next hop on the route to the destination node ID in the VNS header. A forwarding table gets built on each node to help with those decisions 🗺️.

Each VNS instance on each node builds and maintains a forwarding table for its LN. Every forwarding table has an entry for every node that's a member of the logical network 💖.

7.2 Multicast 📣

On top of the unicast forwarding function, VNS also supports a multicast forwarding service for traffic within an LN, at the VNS layer. Multicast packets get delivered to all nodes supporting the logical network the multicast packet belongs to. The packets travel along the branches of a spanning tree that each node supporting the logical network builds, and that tree is based on a common root node, so every node's view of the tree matches 🌳. In other words, multicast packets are sent intelligently and use a minimum of network bandwidth 🧠. If the network topology is stable, each node receives each multicast packet only once 💜.

Multicast packets received at any node are not acknowledged. They just get forwarded to the specified network layer interface and sent on to any other neighbor nodes on the spanning tree 🫧.

8. Traffic Engineering 🚦

VNS forwarding supports two traffic engineering mechanisms: equal cost multipaths and trunk load spreading 💅.

Equal cost multipaths lets different streams (unique network layer source and destination address pairings) get load spread across multiple relatively equal cost paths through the Logical Network to the egress node 🌈.

Trunk load spreading between two neighbors can happen when multiple VNS trunks are defined between those neighbors. Again, the load spreading is based on network layer streams 🎀.

8.1 Equal Cost Multipaths ✨

okay so from any point in a logical network there can be more than one path to reach a specific egress node 🛣️ if VNS routing decides that some of these paths cost the same, VNS packets get load spread across two of them 💖

equal cost multipath forwarding works on tandem nodes too, not just ingress nodes 🫶 every packet gets tagged with an equal cost multipath key on the ingress node. that key gets acted on there and stored in the VNS header so the tandem nodes can use it too 🎀

the key comes from running an algorithm over the source and destination network layer addresses. so in a stable network, any given stream always takes the same path through a Logical Network 🦋 which means no misordering problems, and that's honestly so iconic 😭

8.2 Trunk Load Spreading Between Neighbors

okay bestie, VNS lets you configure multiple trunks between neighboring VNS nodes 🌸 VNS routing looks at the aggregate bandwidth of those trunks to figure out the metric between the nodes. and VNS load spreads its traffic across those trunks too 💅

same energy as equal cost multipaths here: the trunk load spreading key gets calculated on the ingress node, from an algorithm run over the source and destination network layer addresses ✨ then the key gets stored in the VNS header so every tandem node through the Logical Network can use it 🧚

9. Class of Service

at the ingress to a VNS Network, packets get classified according to the Class of Service (Cos) policy settings 💜 the CoS differentiation happens through different Emission and Discard priorities 🔥 the classification info rides along in the VNS label (the DP and COS Fields from Section 3). it gets used at the ingress node and at every tandem point in the VNS network to affect queuing and scheduling decisions. main character energy for your packets, periodt 👑

10. VNS Migration Strategies

VNS supports several upper layer protocols, like IP, IPX, and Bridging. so it's a multiprotocol label switching architecture 🌈 it's also not tied to a particular L2 technology. it runs on cell trunks (like ATM), frame trunks, or a mix of both 🍓

VNS can be introduced gradually in a network 🌷 it can be implemented between switching elements connected by point to point links. each of the switching nodes can run layer 3 routing at the same time as packet switching. VNS also allows for interconnecting VNS clouds through an ATM VC 🦢

since VNS can run on a mix of Frame and Cell trunks, it makes graceful migration from frame links to ATM possible, without needing a complete, immediate overhaul 🫶

11. Summary

okay recap time 📝 VNS tackles scalability problems in a few ways:

  1. By a generally distributed design which doesn't require a Label Distribution Protocol, or servers of any kind 🧚
  2. By providing an efficient, distributed multicast mechanism 💫
  3. By allowing administrators to control the size of a Logical Network, limiting traffic to a subset of the physical topology 🎯
  4. By reducing layer 3 address space/subnet requirements in the WAN, which reduces the routing table size 📉

VNS gives you redundancy that's transparent to the network layer protocol, because it manages the network of trunks independently of the network layer 🛡️ VNS automatically discovers any topology changes and re-routes traffic accordingly. no drama ✨

VNS eases network administration by dynamically keeping track of which trunks are available for each LNN 💅 network administrators don't have to configure VNS or network layer addresses on a per link basis. network layer addresses only have to be assigned on a per Logical Network basis. and for nodes that will only be tandem VNS nodes, network layer addresses aren't required at all 🌸

since VNS traffic is constrained within an LNN, administrators get control over where VNS traffic is allowed to flow 🎀

finally, VNS supports switching of several Upper Layer Protocols and several media (cell and Frame), or a mixture of them 🌈 switching in the core of the WAN removes the need for routers and improves performance, because there are fewer fields that need to be processed ⚡

12. Security Considerations

okay, this part is serious bestie 🙈 logical networks give you a way to restrict traffic flow for security purposes. VNS also relies on the inherent security of the L2 media, like an ATM Virtual Circuit 🔐

13. Acknowledgments

the authors want to give a big shoutout to Terry Boland, Pierre Cousineau, Robert Eros, Robert Tomkins, and John Whatman for their valuable comments 🫶💖

14. Authors' Addresses

the squad behind this one, all from Nortel (Northern Telecom), Ltd. in Ottawa 🍁

Bilel Jamoussi Nortel (Northern Telecom), Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada

EMail: jamoussi@Nortel.ca

Dwight Jamieson Nortel (Northern Telecom), Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada

EMail: djamies@Nortel.ca

Dan Williston Nortel (Northern Telecom), Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada

EMail: danwil@Nortel.ca

Stephen Gabe Nortel (Northern Telecom), Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada

EMail: spgabe@Nortel.ca

the legal bit, read it all 🧾

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 🌟

📦 where this page comes from