idnits 2.17.1 draft-shah-ppvpn-ipls-00.txt: -(55): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(153): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(278): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(377): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(405): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(463): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(503): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(514): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(517): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(551): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(657): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(675): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(754): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(783): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 38 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([VPLS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 307: '...N or VLAN, there MUST NOT be more than...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PPVPN-FWK' is mentioned on line 82, but not defined -- Looks like a reference, but probably isn't: '8' on line 481 == Missing Reference: 'PWE3-Control' is mentioned on line 521, but not defined == Unused Reference: 'L2VPN-FMWK' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'PWE3-ETH-ENCAP' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'ARP' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'PROXY-ARP' is defined on line 780, but no explicit reference was found in the text -- No information found for draft-ietf-ppvpn-l2-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L2VPN-FMWK' == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-00 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-00 == Outdated reference: A later version (-03) exists of draft-rosen-ppvpn-l2-signaling-02 -- Possible downref: Normative reference to a draft: ref. 'ROSEN-SIG' == Outdated reference: A later version (-04) exists of draft-lasserre-vkompella-ppvpn-vpls-02 -- Possible downref: Normative reference to a draft: ref. 'VPLS' -- Possible downref: Normative reference to a draft: ref. 'DNS-Discovery' -- No information found for draft-ietf-ppvpn-bgpvpn-auto - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BGP-Discovery' ** Downref: Normative reference to an Unknown state RFC: RFC 925 (ref. 'PROXY-ARP') Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Himanshu Shah 3 K.Arvind 4 Tenor Networks 5 PPVPN Working Group 6 Internet Draft 7 draft-shah-ppvpn-ipls-00.txt Eric Rosen 8 Francois Le Faucheur 9 October 2002 Cisco Systems 10 Expires: March 2003 11 Giles Heron 12 PacketExchange,Ltd 14 Vasile Radoaca 15 Nortel Networks 17 IP over LAN Service (IPLS) 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect 42 systems across a wide-area or metropolitan-area network, making it 43 appear to those systems as if they are interconnected on a private 44 LAN. The systems which are interconnected in this way may 45 themselves be LAN switches. If, however, the interconnected systems 46 are NOT LAN switches, but rather are IP hosts or IP routers, certain 47 simplifications are possible. We call this simplified type of 48 virtual private LAN service an �IP over LAN Service� (IPLS). In 49 IPLS, as in VPLS, LAN interfaces are run in promiscuous mode, and 50 frames are forwarded based on their MAC Destination Addresses. 52 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 54 However, the maintenance of the MAC forwarded tables is done via 55 signaling, rather than via the �MAC Address Learning� procedures of 56 IEEE 802.1D. Further, Address Resolution Protocol (ARP) messages 57 are proxied, rather than being carried transparently. This draft 58 specifies the protocols and procedures for support of the IPLS 59 service. 61 1.0 Boiler Plate for Sub-IP Area Drafts 63 RELATED DOCUMENTS 64 draft-ietf-ppvpn-l2-framework-01.txt 65 draft-lasserre-vkompella-ppvpn-vpls-02.txt 66 draft-rosen-ppvpn-l2-signaling-02.txt 67 draft-ietf-pwe3-control-protocol-00.txt 68 draft-heinanen-inarp-uni-01.txt 70 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 72 Belongs in PPVPN 74 WHY IS IT TARGETED AT THIS WG 76 This document describes a mechanism to assist in Provider- 77 Provisioned Layer 2 VPNs. 79 JUSTIFICATION 81 This document provides a detailed description for IP over LAN 82 Service (IPLS), which is discussed in the L2 PPVPN Framework [PPVPN- 83 FWK]. The VPLS [VPLS] services of L2VPN require PE devices to 84 function as MAC learning bridges. IPLS is a solution for a specific 85 topology where MAC learning capabilities are not required for VPLS 86 services, because user data traffic is restricted to IP, and the CE 87 devices are not LAN switches. 89 2.0 Overview 91 As emphasized in [VPLS], Ethernet has become popular as an access 92 technology in Metropolitan and Wide Area Networks. [VPLS] describes 93 how geographically dispersed customer LANs can be interconnected 94 over a service provider�s network using Layer 2 VPNs. The VPLS 95 service is provided by Provider Edge (PE) devices, and it is 96 provided to Customer Edge (CE) devices. The VPLS architecture 97 provides such services by incorporating bridging functions such as 98 MAC address learning in the PE devices. 100 There are Provider Edge platforms, both existing and forthcoming, 101 which have been designed primarily to be IP routers, rather than to 102 be LAN switches. It can be fairly straightforward to add a MAC 103 address lookup capability to these platforms, and to run their LAN 104 interfaces in promiscuous mode, so that they can forward frames 105 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 107 based on the MAC Destination Address of the frame. It is less 108 straightforward to add the IEEE 802.1D MAC Address learning 109 capability to these platforms. However, in scenarios where the CE 110 devices are NOT LAN switches, but rather are IP hosts or IP routers, 111 it is possible to provide the virtual private LAN service without 112 requiring IEEE 802.1D MAC address learning/aging on the PE. Due to 113 these restrictions, we dub such a service an �IP LAN Service�, or 114 IPLS. The purpose of this draft is to specify the IPLS. 116 Consequently, IPLS allows a service provider to provide a VPLS-like 117 service by using PE routers that are not designed to perform general 118 LAN bridging functions. However one must be willing to accept the 119 restriction that the Virtual LAN service be used for IP traffic 120 only, and not used to interconnect CE devices that are themselves 121 LAN switches. This seems like an acceptable restriction in many 122 environments, given that IP is the predominant type of traffic in 123 today's networks. 125 In IPLS, a PE device implements multi-point LAN connectivity for IP 126 traffic using the following key functions: 128 1. Discovery: Each Provider Edge (PE) device discovers IP/MAC 129 address associations for the locally attached Customer Edge 130 (CE) devices, for each IPLS instance configured on the PE 131 device. 133 2. Pseudowires (PW) for Unicast Traffic: For each locally attached 134 CE device in a given IPLS instance, a PE device sets up a 135 pseudo-wire (VC-LSP) to each of the other PEs that supports the 136 same IPLS instance. 138 For instance, if PEx and PEy both support IPLS I, and PEy is 139 locally attached to CEw and CEz, PEy will initiate the setup of 140 two pseudowires between itself and PEx. One of these will be 141 used to carry unicast traffic from any of PEx�s CE devices to 142 CEw. The other will be used to carry unicast traffic from any 143 of PEx�s CE devices to CEz. 145 Note that these pseudowires carry traffic only in one 146 direction. Further, while the pseudowire implicitly identifies 147 the destination CE of the traffic, it does not identify the 148 source CE; packets from many CEs may be freely intermixed on a 149 given pseudowire. 151 3. Pseudowires for Multicast Traffic: In addition, every PE 152 supporting a given IPLS instance will set up a special 153 �multicast pseudowire� to every other PE in that IPLS instance. 154 If, in the above example, one of PEx�s CE devices sends a 155 multicast packet, PEx would forward the multicast packet to PEy 156 on the special multicast pseudowire. PEy would then send a 157 copy of that packet to CEw and a copy to CEz. 159 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 161 Thus when a PE sends a multicast packet across the network, it 162 sends one copy to each remote PE (supporting the given IPLS 163 instance). If a particular remote PE has more than one CE 164 device in that IPLS instance, the remote PE must replicate the 165 packet and send one copy to each of its local CEs. 167 As with the pseudowires that are used for unicast traffic, 168 packets travel in only one direction on these pseudowires, and 169 packets from different sources may be freely intermixed. 171 4. Signaling: The necessary pseudowires can be set up and 172 maintained using the LDP-based signaling procedures described 173 in [PWE3-CONTROL] and/or [ROSEN-SIG]. Use of other signaling 174 procedures is for further study. 176 A PE may assign the same label to each of the unicast 177 pseudowires that leads to a given CE device, in effect creating 178 a multipoint-to-point pseudowire. 180 Similarly, a PE may assign the same label to each of the 181 multicast pseudowires for a given IPLS instances, in effect 182 creating a multipoint-to-point pseudowire. 184 When setting up a pseudowire to be used for unicast traffic, 185 the PE must also signal the IP address and the MAC address of 186 the corresponding CE device. 188 5. Proxy ARP: Distribution of IP/MAC address associations to 189 remote PE devices via PW signaling enables each PE device to 190 function as a proxy ARP server for CE devices attached to other 191 PE devices. This makes it possible for any CE device to ARP for 192 the MAC addresses of remote CE devices. 194 6. Forwarding: A PE device programs its Forwarding Information 195 Base using the CE MAC addresses and VC labels signaled through 196 the PW signaling. Unicast IP traffic from the local CEs is then 197 switched to the proper VC-LSP based on the destination MAC 198 address. Multicast IP traffic from the local CEs is replicated 199 by the local PE over all the multicast VC-LSPs for that IPLS 200 instance and is then replicated by each remote PE onto all its 201 Attachment Circuits for that IPLS instance. 203 Both VPLS [VPLS] and IPLS require the ingress PE to forward a frame 204 based on its destination MAC address. However, two key differences 205 between VPLS and IPLS can already be noted from the above 206 description: 208 . In VPLS, MAC entries are placed in the FIB of the ingress PE as 209 a result of IEEE 802.1D MAC address learning (which occurs in 210 the data plane) while in IPLS MAC entries are placed in the FIB 211 as a result of pseudowire signaling operations (control plane). 213 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 215 . In VPLS, the egress PE looks up a frame�s MAC destination 216 address to determine the customer-facing interface out which 217 the frame must be sent; in IPLS, the choice of interface is 218 based entirely on the VC-label. 220 The following sections describe the details of the IPLS scheme. 222 2.1 Terminology 224 IPLS IP over LAN service (class of VPLS for IP 225 only). 227 IPLS network A collection of PE nodes supporting the IPLS 228 service and the mechanisms described in this 229 document, including the Extended LDP based PW 230 signaling between them. 232 IPLS Service A single service instance of IPLS emulating a 233 LAN segment for IP data traffic. 235 MPt-Pt PW Multipoint-to-Point Pseudowire. A pseudowire 236 that carries traffic from remote PE devices to 237 a PE device that signals the pseudowire. The 238 signaling PE device advertises the same VC- 239 label to all remote PE devices that participate 240 in the IPLS service instance. In IPLS, for a 241 given IPLS instance, a MPt-Pt PW used for IP 242 unicast traffic is established by a PE for each 243 CE device locally attached to that PE. It is a 244 unidirectional tree whose leaves consist of the 245 remote PE peers (which connect at least one 246 Attachment Circuit associated with the same 247 IPLS instance) and whose root is the signaling 248 PE. Traffic flows from the leaves towards the 249 root. 251 Multicast PW Multicast Pseudowire. A special kind of MPt-Pt 252 PW that carries only IP multicast/broadcast 253 traffic. In the IPLS architecture, for each 254 IPLS instance supported by a PE, that PE device 255 establishes exactly one Multicast PW. 257 CE Customer Edge device. In this document, a CE is 258 any IP node (host or router) connected to the 259 IPLS LAN service. 261 Replication Tree The collection of all pseudowires and 262 attachment circuits that are members of an IPLS 263 service instance on a given PE. When a 264 multicast/broadcast packet is received by the 265 PE on an attachment circuit, the PE device 266 sends a copy of the packet to every pseudowire 267 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 269 and attachment circuit of the replication tree, 270 excluding the attachment circuit on which the 271 packet was received. 273 3.0 Topology 275 The Customer Edge (CE) devices are IP nodes (hosts or routers) that are 276 connected to PE devices either directly, or via an Ethernet network. We 277 assume that the PE/CE connection may be regarded by the PE as an 278 �interface� to which one or more CEs are attached. This interface may 279 be the physical LAN interface or a VLAN. The Provider Edge (PE) 280 routers are MPLS Label Edge Routers (LERs) that serve as pseudowire 281 endpoints. 283 +----+ +----+ 284 + S1 +---+ ........................... +---| S2 | 285 +----+ | | . . | +----+ 286 IPa | | +----+ +----+ | IPe 287 + +---| PE1|---MPLS and/or IP---| PE2|---+ 288 / \ +----+ |Network +----+ | 289 +----+ +---+ . | . | +----+ 290 + S1 + | S1| . +----+ . +---| S2 | 291 +----+ +---+ ..........| PE3|........... +----+ 292 IPb IPc +----+ IPf 293 | 294 | 295 +----+ 296 | S3 | 297 +----+ 298 IPd 300 In the above diagram, an IPLS instance is shown with three sites: 301 site S1, site S2 and site S3. In site S3, the CE device is directly 302 connected to its PE. In the other two sites, there are multiple CEs 303 connected to a single PE. More precisely, the CEs at these sites are 304 on an Ethernet network (or VLAN), and the PE is attached to that 305 same Ethernet network or VLAN). We impose the following 306 restriction: if one or more CEs attach to a PE by virtue of being 307 on a common LAN or VLAN, there MUST NOT be more than one PE on that 308 LAN or VLAN. 310 PE1, PE2 and PE3 are shown to be connected via an MPLS network; 311 however, other tunneling technologies, such as GRE, L2TP, etc., 312 could also be used to carry the pseudowires. 314 An IPLS instance is a single broadcast domain, such that each IP end 315 station (e.g., IPa) appears to be co-located with other IP end 316 stations (e.g., IPb though IPf) on the same subnet. The IPLS service 317 is transparent to the CE devices and requires no changes to them. 319 4.0 Configuration 320 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 322 Each PE router is configured with one or more IPLS service 323 instances, and each IPLS service instance is associated with a 324 unique VPN-Id. For a given IPLS service instance, a set of 325 Attachment Circuits is identified. Each Attachment Circuit can be 326 associated with only one IPLS instance. An Attachment Circuit, in 327 this document, is either a customer-facing Ethernet port, or a 328 particular VLAN (identified by an IEEE 802.1Q VLAN ID) on a 329 customer-facing Ethernet port. 331 The PE router can optionally be configured with a local MAC address 332 to be used as source MAC address when packets are forwarded from a 333 pseudowire to an Attachment Circuit. By default, a PE uses the MAC 334 address of the customer-facing Ethernet interface for this purpose. 336 5.0 Discovery 338 The discovery process includes: 339 . Remote PE discovery 340 . VPN (i.e., IPLS) membership discovery 341 . IP CE end station discovery 343 This draft does not discuss the remote PE discovery or VPN 344 membership discovery. This information can either be user configured 345 or can be obtained using auto-discovery techniques described in 346 [DNS-Discovery] or [BGP-Discovery]. However, the discovery of the CE 347 is an important operational step in the IPLS model and is described 348 below. 350 5.1 CE discovery 352 Each PE actively detects the presence of local CEs by snooping IP 353 and ARP frames received over the Attachment Circuits. During the 354 discovery phase, the PE examines each broadcast/multicast Ethernet 355 frame. For IP frames (for example IGP discovery/multicast/broadcast 356 packets), the CE�s (source) MAC address is extracted from the 357 Ethernet header and the (source) IP address is obtained from the IP 358 header. For ARP frames, the source MAC and IP address are determined 359 from the ARP PDU. 361 For each CE, the PE maintains a tuple. 364 Once discovered, the presence/liveness of a CE is monitored 365 continuously by examining the received ARP frames and by 366 periodically generating ARP requests. The absence of an ARP response 367 from a CE after a configurable number of such ARP requests, is 368 interpreted as a loss of connectivity with the CE. 370 6.0 Pseudowire Creation 372 6.1 Receive Unicast Multipoint-to-point Pseudowire 373 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 375 As the PE discovers each locally attached CE, a unicast Multipoint- 376 to-point Pseudowire (MPt-Pt PW) associated exclusively with that CE 377 is created by distributing the CE�s IP address and MAC address along 378 with a VC-Label to all the remote PE peers that participate in the 379 same IPLS instance. Note that the same value of a VC-label should be 380 distributed to all the remote PE peers for a given CE. The MP-Pt PW 381 thus created is used by remote PEs to send unicast IP traffic to a 382 specific CE. 384 (The same functionality can be provided by a set of point-to-point 385 PWs, so the PE is not required to send the same VC-label to all the 386 other PEs. For convenience however, we will speak in the following 387 only of multipoint-to-point PWs, without pointing out each time that 388 a set of point-to-point PWs could be used instead.) 390 The PE forwards a frame received over this MPt-Pt PW to the 391 associated attachment circuit. 393 6.2 Receive Replication Multipoint-to-point PseudoWire 395 When a PE is configured to participate in an IPLS instance, it 396 advertises a "multicast" VC-label to every other PE that is a member 397 of the same IPLS. The advertised VC-label value is the same for each 398 PE, which creates a multipoint-to-point pseudowire for IP multicast 399 traffic. There is only one multicast MPt-Pt PW per PE for each IPLS 400 instance and this pseudowire is used exclusively to carry 401 multicast/broadcast IP traffic from the remote PEs to this PE for 402 this IPLS instance. 404 Note that no special functionality is expected from this pseudowire. 405 We sometimes call it a �multicast pseudowire� because we use it only 406 to carry multicast traffic. The pseudowire itself need not provide 407 any different service than any of the unicast pseudowires. 409 In particular, the Receive multicast MPt-PT PW does not perform any 410 replication of frames itself. Rather, it is there to signify to the 411 PE that the PE needs to replicate a copy of a frame received over 412 this MPt-Pt PW onto all the attachment circuits that are associated 413 with the IPLS instance of the MPt-Pt PW. 415 The use of pseudowires, which are specially optimized for multicast, 416 is for further study. 418 6.3 Send Multicast Replication tree 420 The PE creates a send replication tree for each IPLS instance, which 421 consists of the collection of all attachment circuits and all the 422 �multicast� pseudowires of this IPLS instance. 424 Any broadcast/multicast frame received over an attachment circuit is 425 replicated to all the other attachment circuits and all pseudowires 426 of the send replication tree of the IPLS instance of the incoming 427 Attachment Circuit. 429 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 431 7.0 Proxy ARP 433 As part of the signaling of the unicast multipoint-to-point pseudo- 434 wire (See Section 8), each PE distributes to its remote PE peers the 435 CE IP address/MAC address associations that it has discovered. The 436 remote PE peers then build and maintain a database of these 437 associations. 439 When a PE receives an ARP request from a local CE for a remote CE, 440 it searches for the destination IP address in the database 441 associated with the CE�s IPLS instance. If a match is found, the PE 442 sends an ARP response with the MAC address of the remote CE. This 443 enables the local CE to send unicast IP frames addressed directly to 444 the MAC address of the remote CE. 446 8.0 Signaling 448 IPLS uses PW signaling based on LDP as specified in [PWE3-CONTROL] 449 and [ROSEN-SIG] to exchange layer-2 cross-connect information for a 450 given VPN. The cross-connect information is represented as a new LDP 451 FEC element (VC-FEC in [PWE3-CONTROL] with a FEC element type of 452 128, new FEC element in [ROSEN-SIG] with a FEC element type of 129), 453 which LDP then distributes to remote peers in downstream-unsolicited 454 mode. This document proposes extensions to the new FEC element to 455 support the IPLS as a new circuit type and to include the IP address 456 and MAC address information. 458 8.1 IPLS PW Signaling 460 The IPLS VPN type is advertised in the VC-Type field of the VC FEC 461 as the value 0x000D. 463 The �interface parameter� field in the VC FEC is defined in [PWE3- 464 CONTROL] and [ROSEN-SIG] as follows. 466 0 1 2 3 467 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Parameter ID | Length | Variable Length Value | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Variable Length Value | 472 | " | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 The following parameters of the VC FEC are already defined: 476 Parameter ID Length Description 478 0x01 4 Interface MTU in octets. 479 0x02 4 Maximum Number of concatenated ATM cells. 480 0x03 up to 82 Optional Interface Description string. 481 0x04 4 CEM [8] Payload Bytes. 483 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 485 0x05 4 CEM options. 487 The Length field is defined as the length of the interface 488 parameter including the parameter id and length field itself. 490 We propose the following additional parameters for the VC FEC: 492 0x06 4 IP address of CE 493 0x07 6 MAC address of CE 494 0x08 1 Multicast Label Flag 496 These parameters are used to transport CE IP address/MAC address 497 associations when establishing the MPt-Pt unicast PWs and to 498 establish the multicast multipoint-to-point pseudowire label. The IP 499 address and MAC address interface parameter denotes the IP and MAC 500 address of a CE. The Multicast Label Flag value of 1 indicates that 501 the advertised VC-Label represents a �multicast� PW. The Multicast 502 Label Flag value of 0 indicates that advertised VC-label represents 503 a �unicast� PW. As explained earlier, the term �multicast PW� only 504 means that the PW carries IP broadcast/multicast traffic and does 505 not refer to a multicast LSP in the traditional sense. 507 The Multicast Label flag must be zero, if present, when the IP and 508 MAC address parameters are present (and their value is non-zero). 510 We recommend two options that are currently present as the interface 511 parameter field in the VC FEC, for signaling such �VC associated 512 information�. 513 1. The entire �interface parameter� field is either removed or 514 duplicated from the VC FEC to the �optional parameter� field of 515 the LDP�s Label Mapping Message. 516 2. A new VC Status FEC is introduced that accompanies the VC FEC 517 in the LDP�s Label Mapping Message. The �interface parameter� 518 field of the VC FEC is then either removed or duplicated from 519 the VC FEC to the VC Status FEC. 521 We intend to work with authors of [PWE3-Control] and [ROSEN-SIG] to 522 find the most suitable solution for extensions (such as IP address, 523 IP address and MAC address, interface status, etc.) that are 524 generic, in a backward-compatible fashion. 526 The new FEC specified in [ROSEN-SIG] contains an Attachment Group 527 Identifier (AGI) field, a Source Attachment Individual Identifier 528 field (SAII) and a Target Attachment Individual Identifier field 529 (TAII). The VPN-Id configured on the advertising PE to identify the 530 IPLS instance is advertised in the AGI field. The SAII and TAAI 531 fields are set to the null value. 533 8.2 Signaling Advertisement Processing 534 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 536 A PE should process a received [PWE3-CONTROL] advertisement with VC- 537 type of IPLS as follows, 538 - Verify the IPLS VPN membership by matching the VPN-Id 539 signaled in the AGI field with the all the VPN-Ids configured 540 on the PE. Discard and release the VC label if VPN-Id is not 541 found. 542 - Distribute the received IP address-to-MAC address binding by 543 sending a gratuitous ARP response on all the attachment 544 circuits associated with the VPN-Id. 545 - Program the Forwarding Information Base (FIB) such that when 546 a packet is received from an attachment circuit with its 547 destination MAC address matching the advertised MAC address, 548 the packet is forwarded out over the tunnel to the 549 advertising PE with the advertised VC-label as the inner 550 label. 551 - When the advertised VC-label is �multicast�, add the VC-label 552 to the multicast replication tree for the VPN-Id. This 553 enables sending a copy of a multicast/broadcast IP frame from 554 the attachment circuit to this Pseudowire. 556 8.3 Requesting for IP to MAC binding 558 It is possible that in some cases, some CEs may remain undetected in 559 the absence of any multicast/broadcast IP or ARP packet generation. 560 If another CE needs to converse with a CE in this undetected set, it 561 will proceed to generate ARP requests. The Proxy ARP scheme 562 described so far will be unable to resolve the ARP request, since 563 the address to be resolved would not have been discovered yet. 565 In order to address such situations, an optional Address Resolution 566 Request TLV is included in the Label Mapping message. This TLV 567 contains an IP address parameter that represents the destination IP 568 address that needs to be resolved. The PE may use some intelligent 569 mechanisms (e.g., the number of ARP requests received for unknown IP 570 destination within a certain interval exceeds a threshold) to detect 571 the need for such advertisement. When the need is detected, the PE 572 generates Label Mapping Messages to all remote PEs in the IPLS, with 573 the IP address parameter in the Address Resolution Request TLV set 574 to the destination IP address to be resolved. 576 A PE that supports the Address Resolution Request TLV must, on 577 receiving a Label Mapping message with this TLV, generate an ARP 578 request message using the received IP address as the destination, 579 and some already known IP and MAC address as the source (in the ARP 580 PDU) on all Attachment Circuits associated with the IPLS instance. 582 In essence, this is a request to remote PEs to generate an ARP 583 request on their Attachment Circuits to locate a specific CE and 584 advertise a Label Mapping message back to the requesting PE. This 585 can be seen as reverting to the usual full broadcasting of ARP 586 messages throughout the Emulated LAN in case Proxy ARP fails. 588 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 590 9 Forwarding 592 9.1 Non-IP traffic 594 In an IPLS VPN, only IP traffic is forwarded by a PE. ARP frames are 595 directed to the control plane in the PE and the rest of the frames 596 are dropped silently. If the CEs must pass non-IP traffic to each 597 other, they must do so through IP tunnels that terminate at the CEs 598 themselves. 600 9.2 Unicast IP Traffic 602 In IPLS, IP traffic is forwarded based on the destination MAC 603 address of the layer 2 frame (and not based on the IP Header). 605 To do so, the PE uses a Forwarding Information Base (FIB), which is 606 programmed for the considered IPLS instance, in the following 607 manner: 608 - Whenever a CE (and its MAC address) is discovered locally by 609 the PE on an Attachment Circuit, the PE programs its FIB such 610 that frames received on other attachment circuits with a 611 destination address equal to the CE MAC address, are 612 forwarded onto the corresponding attachment circuit. 613 - When advertising the corresponding unicast PW, the PE 614 programs the FIB such that packets received onto the 615 advertised unicast pseudo-wire are forwarded onto the 616 attachment circuit associated with the CE corresponding to 617 the advertised MAC and IP addresses. 618 - As discussed in section 8.2, on receipt of a PW signaling 619 advertisement, the FIB is programmed by the PE receiving the 620 advertisement such that frames received on an Attachment 621 Circuit with a destination address equal to the advertised 622 MAC address, are forwarded onto the advertised unicast 623 pseudowire. 625 Using the FIB of the IPLS instance to which the attachment circuit 626 belongs, the PE forwards a unicast IP frame to the Attachment 627 Circuit or pseudowire based on the destination MAC address 628 information, if received from an Attachment Circuit, or to the 629 Attachment Circuit based on the VC label, if received from a 630 pseudowire. 632 When a unicast destination MAC address is not recognized in the FIB, 633 the IP frame is dropped. 635 9.3 Broadcasts and Multicast forwarding 637 When the destination MAC address is either a broadcast or multicast, 638 a copy of the frame is sent to the control plane for CE discovery 639 purposes (see section 5.1). 641 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 643 When a multicast/broadcast IP frame is received from an Attachment 644 Circuit, a PE replicates it onto the Send Multicast Replication Tree 645 (See section 6.3). When a multicast/broadcast IP frame is received 646 from a pseudowire, the PE forwards it to all attachment circuits 647 associated with the IPLS VPN instance involved. 649 It is important to note that PEs participating in an IPLS VPN are 650 responsible for translating a multicast IP address to a multicast 651 Ethernet MAC address when forwarding frames from a �multicast� 652 pseudowire to the Attachment Circuits. (The translation consists of 653 recognizing the multicast IP address (224.x1.x2.x3) and appending 654 the least significant three bytes of the IP address to 0x01-00-05 to 655 construct the MAC address, e.g., 0x01-00-5E-x1-x2-x3 [RFC-1112]). 657 All other IP packets received over the �multicast� MPt-Pt PW (such 658 as directed broadcasts, subnet broadcasts, etc) are forwarded over 659 Attachment Circuits using a broadcast MAC address. 661 9.4 Encapsulation 663 The Ethernet MAC header of a frame received from an Attachment 664 Circuit is stripped before forwarding the frame to the appropriate 665 pseudowire. However, the MAC header is retained when a unicast or 666 broadcast IP frame is directed to one or more Attachment Circuit(s). 667 An IP frame received over a pseudowire is prepended with a MAC 668 header before transmitting it on the appropriate Attachment 669 Circuit(s). The fields in the MAC header are filled in as follows: 670 - The destination MAC address is the MAC address associated 671 with the VC label in the FIB when the pseudowire is unicast 672 - The destination MAC address is a multicast MAC address 673 derived from the IP multicast address or the broadcast MAC 674 address when the VC label is �multicast� 675 - The source MAC address is the PE�s own local MAC address or a 676 MAC address which has been specially configured on the PE for 677 this use. 678 - The Ethernet Type field is 0x0800 679 - The frame may get IEEE802.1Q tagged based on the VLAN 680 information associated with the Attachment Circuit. 682 An FCS field is appended to the frame. 684 10.0 Attaching to IPLS via ATM or FR 686 In addition to (i) an Ethernet port and a (ii) combination of 687 Ethernet port and a VLAN ID, an Attachment Circuit to IPLS may also 688 be (iii) an ATM or FR VC carrying encapsulated bridged Ethernet 689 frames or (iv) the combination of an ATM or FR VC and a VLAN ID. 691 The ATM/FR VC is just used as a way to transport Ethernet frames 692 between a customer site and the PE. The PE terminates the ATM/FR VC 693 and operates on the encapsulated Ethernet frames exactly as if those 694 were received on a local Ethernet interface. Operation of an IPLS 695 over ATM/FR VC is exactly as described above, with the exception 696 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 698 that the attachment circuit is then identified via the ATM VCI/VPI 699 or Frame Relay DLCI (instead of via a local Ethernet port ID), or a 700 combination of those with a VLAN ID. 702 11.0 VPLS vs IPLS 704 The VPLS approach proposed in [VPLS] provides VPN services for IP as 705 well as other protocols. The IPLS approach described in this draft 706 is similar to VPLS in many respects: 707 - It provides a Provider Provisioned Virtual LAN service with 708 multipoint capability where a CE connected via a single 709 attachment circuit can reach many remote CEs 710 - It appears as a broadcast domain and a single subnet 711 - forwarding is based on destination MAC addresses 713 However, unlike VPLS, IPLS is restricted to IP traffic only. By 714 restricting the scope of the service to the predominant type of 715 traffic in today's environment, IPLS eliminates the need for service 716 provider edge routers to implement some bridging functions such as 717 MAC address learning in the data path (by, instead, distributing MAC 718 information in the control plane). Thus this solution offers a 719 number of benefits: 721 - Facilitates Virtual LAN services in instances where PE 722 devices cannot or cannot efficiently (or are specifically 723 configured not to) perform MAC address learning. 724 - Does not require flooding of ARP frames. 725 - Encapsulation is more efficient (MAC header is stripped) 726 while traversing the backbone network. 727 - PE devices are not burdened with the processing overhead 728 associated with traditional bridging (e.g., STP processing, 729 etc.). Note however that some of these overheads (e.g., STP 730 processing) could optionally be turned-off with a VPLS 731 solution in the case where it is known that only IP devices 732 are interconnected. 733 - Loops (perhaps through backdoor links) are minimized since a 734 PE could easily reject (via label release) a duplicate IP to 735 MAC address advertisement. 737 12.0 Acknowledgements 739 Authors would like to thank Nigel Burmeister and others at Tenor 740 Networks for their valuable comments. 742 13.0 Security Considerations 744 The security aspects of this solution will be discussed at a later 745 time. 747 14.0 References 748 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 750 [L2VPN-FMWK] Andersson, draft-ietf-ppvpn-l2-framework-01.txt, PPVPN 751 L2 Framework, August 2002, (work in progress). 753 [PWE3-CONTROL] Martini et. Al., �Transport of Layer 2 Frames Over 754 MPLS�, draft-ietf-pwe3-control-protocol-00.txt, August 2002 (work in 755 progress) 757 [PWE3-ETH-ENCAP] Martini et. Al., �Encapsulation Methods for 758 Transport of Ethernet Frames over IP/MPLS Networks�, draft-ietf- 759 pwe3-ethernet-encap-00.txt, August 2002 (work in progress) 761 [ROSEN-SIG] Rosen, �LDP-based Signaling for L2VPNs�, draft-rosen- 762 ppvpn-l2-signaling-02.txt. September 2002. (work in progress). 764 [VPLS] Lasserre et al, �Virtual Private LN Service over MPLS�, 765 draft-lasserre-vkompella-ppvpn-vpls-02.txt, June 2002 (work in 766 progress). 768 [DNS-Discovery] "DNS/LDP Based VPLS", Heinanen, draft-heinanen-dns- 769 ldp-vpls-00.txt, June 2002 771 [BGP-Discovery] �Using BGP as an Auto-Discovery Mechanism for 772 Network Based VPNs�, Ould-Brahim et al., draft-ietf-ppvpn-bgpvpn- 773 auto-02.txt, February 2002, (work in progress). 775 [ARP] Plummer, D., "An Ethernet Address Resolution Protocol: Or 776 Converting Network Protocol Addresses to 48.bit Ethernet 777 Addresses for Transmission on Ethernet Hardware", STD 37, RFC 826, 778 November 1982. 780 [PROXY-ARP] Postel, J., "Multi-LAN Address Resolution", RFC 925, 781 October 1984. 783 [RFC-1112] Deering, S., �Host Extensions for IP Multicasting�, RFC 784 1112, August, 1989. 786 15.0. Intellectual Property Considerations 788 Tenor Networks may seek patent or other intellectual property 789 protection for some or all of the technologies disclosed in this 790 document. If any standards arising from this document are or become 791 protected by one or more patents assigned to Tenor Networks, 792 Tenor intends to disclose those patents and license them on 793 reasonable and non-discriminatory terms. 795 Author's Address 797 Himanshu Shah 798 K.Arvind 799 Tenor Networks 800 100 Nagog Park 801 Internet Draft draft-shah-rosen-heron-ppvpn-IPLS-00.txt 803 Acton, MA 01720 804 Email: hshah@tenornetworks.com 805 Email: arvind@tenornetworks.com 807 Eric Rosen 808 Cisco Systems 809 300 Apollo Drive, 810 Chelmsford, MA 01824 811 Email: erosen@cisco.com 813 Giles Heron 814 PacketExchange Ltd. 815 The Truman Brewery 816 91 Brick Lane 817 LONDON E1 6QL 818 United Kingdom 819 Email: giles@packetexchange.net 821 Francois Le Faucheur 822 Cisco Systems, Inc. 823 Village d'Entreprise Green Side - Batiment T3 824 400, Avenue de Roumanille 825 06410 Biot-Sophia Antipolis 826 France 827 Email: flefauch@cisco.com 829 Vasile Radoaca 830 Nortel Networks 831 Email: vasile@nortelnetworks.com