idnits 2.17.1 draft-rfced-info-vns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 130 has weird spacing: '...e first node ...' == Line 159 has weird spacing: '... in the netwo...' == Line 161 has weird spacing: '...oss the netwo...' == Line 177 has weird spacing: '...ss node ident...' == Line 225 has weird spacing: '...ique to the...' == (6 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9539 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES SETP 1998 INTERNET DRAFT 2 Network Working Group B. Jamoussi 3 INTERNET DRAFT D. Jamieson 4 Category: Informational D. Williston 5 S. Gabe 6 Nortel (Northern Telecom) Ltd. 7 March 1998 9 Nortel's Virtual Network Switching (VNS) Overview 10 12 Status of This Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 To learn the current status of any Internet-Draft, please check 26 the "1id-abstracts.txt" listing contained in the Internet- 27 Drafts Shadow Directories on ftp.is.co.za (Africa), 28 ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), 29 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 31 Distribution of this document is unlimited. 33 Abstract 35 This document provides an overview of Virtual Network Switching 36 (VNS). 38 VNS is a multi-protocol switching architecture that provides COS- 39 sensitive packet switching, reduces the complexity of operating 40 protocols like PPP and frame relay, provides logical networks and 41 traffic segregation for Virtual Private Networks (VPNs), security and 42 traffic engineering, enables efficient WAN broadcasting and 43 multicasting, and reduces address space requirements. VNS reduces or 44 the number of routing hops over the WAN by switching packets based on 45 labels. 47 VNS has been proven in production networks for several years. 49 Table of Contents 51 1 Introduction ............................................ 2 52 2 What is VNS? ............................................ 3 53 3 VNS Header ............................................. 4 54 4 VNS Label Distribution .................................. 6 55 5 Logical Networks (LNs) .................................. 6 56 6 VNS Routing ............................................. 7 57 7 VNS Forwarding .......................................... 8 58 7.1 Unicast .............................................. 8 59 7.2 Multicast ............................................ 8 60 8 Traffic Engineering ..................................... 9 61 8.1 Equal Cost Multipaths ................................ 9 62 8.2 Trunk Load Spreading ................................. 9 63 9 Class of Service ........................................ 10 64 10 VNS Migration Strategies ................................ 10 65 11 Summary ................................................. 10 67 12 Security Considerations ................................. 11 68 13 Acknowledgments ......................................... 11 69 14 Author's Address ........................................ 11 71 1. Introduction 73 There are several key problem areas with today's wide area backbone 74 networks that carry LAN traffic: scalability, service 75 differentiation, redundancy, administration, and traffic containment. 77 First, scalability is becoming a major concern because of the rapid 78 growth in bandwidth demand and geographical reach. As the size of the 79 WAN network grows traditional point-to-point and NBMA topologies or 80 network models lose their performance. 82 Second, the need to provide several Classes of Service (CoS) has 83 never been greater. The days of a single "best effort" service are 84 over and service providers demand ways to differentiate the quality 85 of the service offered to their clients based on several policies. 87 Third, the WAN is often carrying mission-critical traffic and loss of 88 service is not acceptable. So far, path redundancy has been addressed 89 inefficiently by requiring additional links or VCs. 91 Fourth, network operators demand easy and simplified network 92 administration. Large NBMA topologies require extensive PVC 93 provisioning until SVC deployment becomes more ubiquitous. For 94 Point-to-point models, IP address space may be used inefficiently and 95 non-trivial network schemas are required to contain reserved address 96 space. 98 Finally, proper segregation of traffic is becoming a must. This 99 requirement is being addressed today by adding leased lines or VCs 100 used to separate traffic flows based on regions or interest or 101 protocol. 103 Nortel's Virtual Network Switching (VNS) is a technology that 104 provides efficient solutions to these challenges. 106 Section 2 provides an overview of VNS. The VNS header is specified in 107 Section 3. Section 4 describes the VNS label distribution mechanism. 108 Section 5 defines how a VNS network can be partitioned into Logical 109 Networks (LN). Section 6 outlines VNS routing. Section 7 defines both 110 unicast and multicast forwarding. Section 8 describes the mechanisms 111 used to engineer the traffic. Section 9 defines the COS based 112 switching of VNS. Section 10 provides network migration scenarios 113 using VNS. A summary of VNS is provided in Section 11. 115 2. What is VNS? 117 Virtual Network Switching (VNS) is a CoS-sensitive multi-protocol 118 label switching architecture that reduces or eliminates the number of 119 layer 3 hops over the WAN by switching traffic based on labels. 121 VNS makes a network of point to point links (trunks) appear to be a 122 single LAN (broadcast, multiple access) media. The network used by a 123 particular instance of VNS is called a Logical Network (LN) which are 124 described in more detail in Section 5. 126 A LAN packet is encapsulated in a VNS header as it enters the LN and 127 the label in the header is used to switch the packet across the LN. 128 The encapsulation header contains the identifier of the last node (or 129 egress node) that processes the packet as it traverses the LN. It is 130 the first node (or ingress node) that decides to which egress node 131 the packet is sent. All nodes between the ingress and egress nodes 132 (known as tandem nodes) decide independently the best packet 133 forwarding route to the egress node identified in the packet. 135 The network layer protocols view VNS as a shared broadcast media, 136 where the speed to reach any node on the media is the same for all 137 nodes. VNS ensures that traffic destined to other nodes is forwarded 138 optimally. This transparent view of the VNS means that all the 139 details of the network (for example, topology and link states) can be 140 hidden from the Upper Layer Protocols (e.g. Layer 3 routing 141 protocols) and their applications. VNS also ensures that changes to 142 topology or link state are hidden. 144 The network layer protocol on the ingress node views the network 145 layer protocol on the egress node as its logical and directly 146 connected neighbor. This is significant because the network layer 147 protocols always decide which directly connected neighbor should 148 receive a forwarded packet. The details of the actual topology 149 supporting the connectionless network are managed entirely by the 150 Virtual Network Switching and are hidden from the network layer 151 protocols. To the network layer, VNS simply appears to be another 152 Data Link Layer (or media), even though VNS is a network layer itself 153 running on top of the actual Data Link Layer (for example, ATM 154 trunks). 156 For the ingress node to choose the egress node that provides the best 157 path to the packet's final destination, it must have knowledge of the 158 following: 159 - the nodes that can be reached in the network 160 - the topology of the network that is using the VNS services for 161 transport across the network (but not necessarily the topology of 162 the full network) 164 This knowledge is obtained through the network layer routing 165 mechanisms such as, IP's Open Shortest Path First (OSPF) and Address 166 Resolution Protocol (ARP). 168 Once the network layer protocol on the ingress node has decided which 169 neighbor to transmit the packet to, it is the responsibility of VNS 170 forwarding, a part of VNS, to deliver the packet to that node. Once 171 the packet arrives at the egress node, the packet is delivered to the 172 network layer protocol, which then forwards it to its ultimate 173 destination. 175 Tandem nodes have no interaction with the network layer protocols. 176 They only require knowledge of the VNS network topology. They make 177 their packet forwarding decision on the egress node identifier and 178 LN identifier carried in the VNS header of the packet. 180 3. VNS Header 182 VNS defines a unicast header shown in Figure 1 and a multicast header 183 shown in Figure 2. 185 3 2 1 0 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | TTL | LNN |x|LS-Key |x|DP | CmnHdr | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Protocol Type | Destination Node Identifier | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | COS |x x x x| Source Node Identifier | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Network Layer Header (e.g. IP) | 195 / / 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Data | 198 / / 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1. Unicast VNS Header 203 The unicast header includes the following fields: 205 - Common Header (CmnHdr) : The common header identifies the packet to 206 be a VNS encapsulated packet. 208 - Discard Priority: Indicates the level of congestion at which the 209 packet should be discarded. The value of this field is assigned on 210 the originating node based on policy information (see Section 9). 212 - Load Spreading Key: indicates the stream to which the packet 213 belongs for the purposes of equal cost multipath and trunk load 214 spreading (see Section 8). 216 - LNN: The Logical Network Number defines the logical network the 217 packet belongs to. This field in is used in conjunction with the 218 destination node identifier as the VNS switching label (see Section 219 5). 221 - TTL: The Time To Live field is used to detect and discard packets 222 caught in temporary routing loops. 224 - Destination Node Identifier: This field contains an ID which 225 uniquely identifies the destination node. This ID is unique to the 226 physical network not just the LN. In conjunction with the LNN, this 227 forms a global VNS switching label. 229 - Protocol Type: indicates the type of Network layer protocol being 230 carried in the packet. Examples include IP, IPX, and Bridging. If the 231 packet is a multicast packet then this is indicated in this field. 233 - Source Node Identifier: This field contains an ID which uniquely 234 identifies the source node (ingress node). 236 - CoS: The Class of Service field is used to provide routing class of 237 service. The COS field also affects the Emission Priority of the 238 packet in the scheduler (see Section 9). 240 - Reserved Fields: All the fields marked with "x" are Reserved. 242 3 2 1 0 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | TTL | LNN |x|LS-Key |x|DP | CmnHdr | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | PT =3D Multicast| Destination Node Identifier | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | COS |x x x x| Source Node Identifier | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Protocol Type |x x x x x x x x| Multicast Group | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Network Layer Header (e.g. IP) | 254 / / 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 / Data / 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 2. Multicast VNS Header 261 The multicast header shown in Figure 2, includes all the fields of 262 the unicast header. In addition, the multicast header includes the 263 following fields: 265 - Multicast Group: this field is used to identify a sub-group within 266 the logical network that receives the multicast packets. 268 - Protocol Type: indicates the type of Network layer protocol being 269 carried in the packet. Examples include IP, IPX, and Bridging. 271 4. VNS Label Distribution 273 Label distribution in VNS is based on a distributed serverless 274 topology driven approach. Standard ARP or address gleaning is used to 275 distribute and map network layer addresses to VNS addresses. 277 A VNS Label is an 8 byte encoding of the LNN and the node id. VNS 278 Labels are treated as MAC addresses by the network layer. This means 279 that labels are distributed by the same means network layers use to 280 distribute MAC addresses. Thus, VNS leverages existing L2/L3 mapping 281 techniques and doesn't require a separate Label Distribution 282 Protocol. 284 5. Logical Networks (LNs) 286 A logical network consists of a subset of the nodes in a network 287 together with a subset of the trunking facilities that link those 288 nodes. Logical networks partition the network into subnetworks that 289 serve a subset of the overall topology. 291 Each of the logical networks supported on any given node has a 292 separate routing and forwarding table (built by VNS). Therefore, 293 routing decisions are based on the resources available to the logical 294 network, not the entire network. 296 Each instance of VNS will discover all the trunks which are connected 297 to neighbors which support a matching LNN. This provides a huge 298 administrative saving, since VNS provisioning is on a per-node basis, 299 not on a per-link basis. VNS provisioning requires only a unique 300 node id and an LNN. Discovery of which trunks support which LNNs is 301 done at run time, relieving administrative effort, and allowing the 302 LN to dynamically adapt to topology changes. 304 Multiple Logical Networks provide the following benefits to the 305 network system: 307 - Logical networks allow service providers to service multiple 308 private networks or (Virtual Private Internets) easily over one 310 network. 312 - Logical networks can be used to limit the impact of one 313 network layer protocol on the others. This is particularly true for 314 protocols that broadcast or multicast a large percentage of either 315 their control or data packets. This increases the effective 316 bandwidth of the trunks and allows the overall network to scale 317 better. 319 - Logical networks allow for the configuration of the network to 320 meet individual community of interest and geographical subnetworking 321 needs. 323 - Routing control traffic has significance only in the local 324 subnetwork that is isolated to that subnetwork. 326 - Logical networks allow different instances of the same 327 protocol to share trunk facilities. 329 6. VNS Routing 331 VNS routing is a link state routing system which uses many concepts 332 similar to OSPF and PNNI. One of the most significant departures from 333 the others is its ability to calculate shortest path trees and 334 spanning trees for Logical Networks. 336 There is only one type of interface that VNS routing supports and 337 this is known as a VNS link. A link is a set of trunks that join two 338 VNS neighbor nodes. Each node in a VNS network maintains information 339 about the state of locally attached links. This information is 340 flooded throughout the network whenever there is a significant change 341 to the link's state or attributes (i.e. up/down, speed change, 342 available bandwidth change). 344 Each node stores and forwards the link state information received 345 from all other nodes. This allows each node to have the same view of 346 all of the nodes in the network together with all of their link state 347 information. This data is used to compute both the shortest path to 348 reach each node in the Logical Network and a spanning tree for the 349 Logical Network. 351 Logical networks are not bound to a particular trunk or link. They 352 are configured on a node. By default, a link will support a specific 353 logical network if the two nodes which it connects both are 354 configured to support the logical network number. This provides a 355 significant savings in operations over having to configure logical 356 networks on links or trunks. 358 When a link first comes into service, a protocol is run which allows 359 the two neighboring nodes to exchange information about the logical 360 networks they support. This allows the two nodes to determine if the 361 links are to be considered as a locally attached link for a logical 362 network. 364 7. VNS Forwarding 366 VNS supports two types of forwarding: unicasting and multicasting. In 367 the first type, the data packet arrives on the ingress node and 368 unicasting forwards the data packet to a single destination (egress 369 node). In the second type, the data packet arrives on the ingress 370 node and multicasting forwards the data packet to all other nodes in 371 the logical network. 373 7.1 Unicast 375 When a packet first enters the LAN internetwork, the network layer 376 routing protocol determines the best route for the packet to reach 377 its final destination. If the best route is through a VNS Logical 378 Network, the network layer routing protocol relies on VNS forwarding 379 to get the packet to the egress node. A VNS packet header containing 380 the nodeId (the unique ID assigned to each node) of the egress node 381 is added to the front of the packet and VNS forwarding is invoked to 382 deliver the packet. The network layer routing protocol learns the 383 egress nodeId through an Address Resolution Protocol (ARP) or address 384 gleaning. 386 As the packet traverses the LN, routing decisions are made to 387 determine the next hop in the route to reach the destination nodeId 388 specified in the VNS header. A forwarding table is built on each node 389 that assists in making the routing decision. 391 Each Virtual Network Switching on each node builds and maintains a 392 forwarding table for its LN. Each forwarding table has an entry for 393 every node that is a member of the logical network. 395 7.2 Multicast 397 In addition to the unicast forwarding function, VNS also supports a 398 multicast forwarding service. Multicast packets are delivered to all 399 nodes supporting the logical network to which the multicast packet 400 belongs. The packets are sent along the branches of a spanning tree 401 that is built by each node supporting the logical network and is 402 based on a common root node (so that each node's view of the tree is 403 the same as other nodes). In other words, multicast packets are sent 404 intelligently, consuming a minimum of network bandwidth. If the 405 network topology is stable, each node receives each multicast packet 407 only once. 409 Multicast packets received at any node are not acknowledged. They are 410 simply forwarded to the specified network layer interface and sent to 411 any other neighbor nodes on the spanning tree. 413 8. Traffic Engineering 415 VNS forwarding supports two types of traffic engineering mechanisms: 416 equal cost multipaths and trunk load spreading. 418 Equal cost multipaths allows different streams (unique network layer 419 source and destination address pairings) to be load spread between 420 multiple relatively equal cost paths, through the Logical Network to 421 the egress node. 423 Trunk load spreading between two neighbors can take place when 424 multiple VNS trunks are defined between neighbors. Again, the load 425 spreading is based on network layer streams. 427 8.1 Equal Cost Multipaths 429 From any point in a logical network, there may be multiple paths to 430 reach a specific egress node. If VNS routing determines that more 431 than one of these paths are of equal cost, VNS packets will be load 432 spread between two of them. 434 Equal cost multipath forwarding is supported not only on ingress 435 nodes but on tandem nodes as well. Each packet on an ingress node is 436 tagged with an equal cost multipath key. This key is acted upon on 437 the ingress node and stored in the VNS header to be used on tandem 438 nodes. 440 The equal cost multipath key is calculated by running an algorithm 441 over the source and destination network layer addresses. This means 442 that, in a stable network, any given stream will always take the same 443 path through a Logical Network avoiding the problems that misordering 444 would otherwise cause. 446 8.2 Trunk Load Spreading Between Neighbors 448 VNS allows multiple trunks to be configured between neighboring VNS 449 nodes. VNS routing considers the aggregate bandwidth of those trunks 450 to determine the metric between the nodes. Also, VNS load spreads its 451 traffic amongst those trunks. 453 As is the case with equal cost multipaths, the trunk load spreading 454 key is calculated on the ingress node from an algorithm run over the 456 source and destination network layer addresses. The key is then 457 stored in the VNS header to be used on all tandem nodes through the 458 Logical Network. 460 9. Class of Service 462 At the ingress to a VNS Network, packets are classified according to 463 the Class of Service (Cos) policy settings. The CoS differentiation 464 is achieved through different Emission and Discard priorities. The 465 semantics of the classification is carried in the VNS label (DP and 466 COS Fields described in Section 3) to be used at the ingress node as 467 well as all tandem points in the VNS network to affect queuing and 468 scheduling decisions. 470 10. VNS Migration Strategies 472 VNS supports several upper layer protocols such as IP, IPX, and 473 Bridging. Therefore, it is a multiprotocol label switching 474 architecture. In addition, VNS is not tied to a particular L2 475 technology. It runs on cell (e.g., ATM) trunks, frame trunks, or a 476 mixture of both. 478 VNS can be gradually introduced in a network. It can be implemented 479 between switching elements interconnected by point to point links. 480 Each of the switching nodes can run layer 3 routing simultaneously 481 with packet switching. VNS also allows for the interconnection of VNS 482 clouds through an ATM VC. 484 Since VNS can run on a mixture of Frame and Cell trunks, it allows 485 for the graceful migration of the frame links to ATM without 486 requiring a complete immediate overhaul. 488 11. Summary 490 VNS addresses scalability problems in several ways: 492 1. By a generally distributed design which doesn't 493 require a Label Distribution Protocol, or servers 494 of any kind. 495 2. By providing an efficient, distributed multicast mechanism. 496 3. By allowing administrators to control the size of a 497 Logical Network, limiting traffic to a subset of the 498 physical topology. 499 4. By reducing layer 3 address space/subnet requirements in the WAN 500 which reduces the routing table size. 502 VNS provides redundancy transparent to the network layer protocol by 503 managing the network of trunks independently of the network layer. 505 VNS will automatically discover any topology changes and re-route 506 traffic accordingly. 508 VNS eases network administration by dynamically keeping track of 509 which trunks are available for each LNN. Network administrators 510 don't have to configure VNS or network layer addresses on a per link 511 basis. Network layer addresses only have to be assigned on a per 512 Logical Network basis. For nodes which will only be tandem VNS 513 nodes, network layer addresses aren't required at all. 515 Since VNS traffic is constrained within an LNN, administrators have 516 control of where VNS traffic is allowed to flow. 518 Finally, VNS supports switching of several Upper Layer Protocols and 519 supports several media (cell and Frame) or a mixture thereof. 520 Switching in the core of the WAN removes the need for routers and 521 improves the performance due to a reduction in the number of fields 522 that need to processed. 524 12. Security Considerations 526 Logical networks provide a means of restricting traffic flow for 527 security purposes. 529 13. Acknowledgments 531 The authors would like to acknowledge the valuable comments of Terry 532 Boland, Pierre Cousineau, Robert Eros, Robert Tomkins, and John 533 Whatman. 535 14. Author's Address 537 Bilel Jamoussi 538 Nortel (Northern Telecom), Ltd. 539 PO Box 3511 Station C 540 Ottawa ON K1Y 4H7 541 Canada 543 EMail: jamoussi@Nortel.ca 545 Dwight Jamieson 546 Nortel (Northern Telecom), Ltd. 547 PO Box 3511 Station C 548 Ottawa ON K1Y 4H7 549 Canada 551 EMail: djamies@Nortel.ca 553 Dan Williston 554 Nortel (Northern Telecom), Ltd. 555 PO Box 3511 Station C 556 Ottawa ON K1Y 4H7 557 Canada 559 EMail: danwil@Nortel.ca 561 Stephen Gabe 562 Nortel (Northern Telecom), Ltd. 563 PO Box 3511 Station C 564 Ottawa ON K1Y 4H7 565 Canada 567 EMail: spgabe@Nortel.ca 569 INTERNET DRAFT EXPIRES MARCH 1998 INTERNET DRAFT