Internet Draft Network Working Group Tissa Senevirathne Internet Draft Paul Billinghurst Document: draft-tsenevir-8021qospf-00.txt Category: Informational Nortel Networks October 2000 Distribution of 802.1Q VLAN information using Opaque LSA Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document presents the use of opaque LSAs to distribute 802.1Q VLAN information across an Autonomous System. The concept of VLAN domains and the identification and distribution of domain specific VLAN information is discussed. Senevirathne Informational - March 2001 1 draft-tsenevir-8021qospf-00.txt October 2000 Table of Content 1. Conventions used in this document..................................2 2. Introduction.......................................................2 3. Opaque LSA overview................................................3 3.1 Opaque LSA Types and VLAN flooding Scope..........................4 4. VLAN LSA ID........................................................5 5. VLAN distribution TLV format.......................................5 6. Top Level TLV definitions..........................................6 6.1. Domain ID TLV....................................................6 6.2. Router ID TLV....................................................7 6.3 BPDU TAG TLV......................................................8 6.4 VLAN Distribution TLV.............................................8 6.4.1 Top level VLAN Distribution TLV format..........................9 6.4.2 VLAN sub-TLV format.............................................9 6.4.3 Scope Label Sub-TLV............................................10 6.4.4. Service Sub-TLV...............................................11 6.4.5 Encoding of the VLAN sub TLV...................................11 7. Global Service TLV................................................12 7.1 Global Service TLV format........................................12 7.2 Global Service TLV sub-Types.....................................13 8. Encoding of Top Level TLVs........................................13 9. Processing of the VLAN Distribution LSA...........................13 10. Security Considerations..........................................14 11. References.......................................................14 12. Acknowledgments..................................................14 13. Author's Addresses...............................................15 Full Copyright Statement.............................................16 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 2. Introduction There are several discussions and papers published on transporting layer 2 traffic over MPLS networks. MPLS label defines the forwarding of the packet as opposed to Network Layer information in classical routing. Label based forwarding of Layer 3 packets has lead to the popularity of MPLS in transporting non IP data over IP networks. In this scenario the IP network layer is merely the control plane used to establish the label switched data path. Recently published papers on transportation of layer 2 traffic across MPLS networks such as [3], assume static configuration of specified layer 2 information such as VLANs and end router information. With large layer 2 networks, such static configuration lead to administrative burden. This paper presents a dynamic method for distributing and maintaining VLAN information within an autonomous system. Senevirathne Informational - March 2001 2 draft-tsenevir-8021qospf-00.txt October 2000 Within a given autonomous system it is anticipated there will be multiple VLAN domains. The term "domains" is used here to describe VLAN topologies which are mutually exclusive within a defined autonomous system. To reflect this, we define a new concept called "VLAN domain identifier" Distributed VLAN information is interpreted within the scope of a "VLAN domain" This paper utilizes Opaque LSAs defined in [4] to distribute the required VLAN information. Opaque LSAs provide the necessary flexibility to allow the required information to be transmitted within their payload. Opaque LSAs define 3 different distribution scopes. These distribution scopes are ideally suited to distribute VLAN information, either locally, within an area or throughout an entire autonomous system. 3. Opaque LSA overview Opaque LSAs were introduced in [4] as a means of distributing additional information using the OSPF protocol. Opaque LSAs were designed such that the payload of the LSA could contain information that has meaning only within a certain application. The scope of the application is defined by the Opaque Type. Opaque LSA header is summarized below. Note fields not discussed are used as specified in [4] 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10 or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Pay Load | + + | ... | Opaque Type Defines that this LSA is caring VLAN distribution information. Opaque ID Senevirathne Informational - March 2001 3 draft-tsenevir-8021qospf-00.txt October 2000 A unique 24 bit number that identify this LSA instance Pay Load Contain VLAN distribution information in Type/Length/Value (TLV) format. 3.1 Opaque LSA Types and VLAN flooding Scope Three types of Opaque LSA have been defined. Each type has a different flooding scope. Based on administrative requirements, different LSA types may be used to distribute VLAN and service information. Based either on application or administrative requirements it may be necessary to flood VLAN information across the entire autonomous system, within a single area or just to the local subnet. To achieve this we propose a locally configurable parameter "VLAN flooding scope". Each VLAN entry or range of entries may have its own flooding scope. In another words "VLAN flooding scope" is not a system wide configuration but a per VFEC[3] definition. Accordingly we define three VLAN flooding scopes as below: Local Scope LSA Type 9 is chosen for this. LSAs of type 9 are flooded only within the local sub-network. Thus all VLAN (VFEC) information that is to be restricted to the local subnet needs to be configured with a VLAN flooding scope of Local Scope. Area Scope LSA Type 10 is chosen for this. LSAs of type 10 are flooded throughout the local area. Thus all VLAN (VFEC) information that is to be restricted to the local area needs to be configured with a VLAN flooding scope of Area Scope. Global Scope LSA Type 11 is chosen for this. LSA of type 11 are flooded throughout the entire autonomous system. Thus all VLAN (VFEC) information that is required to be available through out the entire autonomous system must be configured with a VLAN flooding scope of Global Scope. Note on Stub Areas and Not So-Stubby Areas (NSSA) LSAs of Type 11 are not flooded to stub areas or NSSAs[4]. Hence special note should be taken when VLAN reacahbility is required to devices which reside in these area types. Devices within these areas Senevirathne Informational - March 2001 4 draft-tsenevir-8021qospf-00.txt October 2000 should be statically configured with the required VFEC reachability information. 4. VLAN LSA ID [4] Defines LSA ID as 8 bits for the Opaque Type and 24 bits for the Opaque ID. Opaque IDs 0-127 are already allocated or reserved by IANA. Values 128-255 are available for private or experimental usage. At present we suggest use of Opaque Type 129 for the distribution of VLAN information. However, if this proposal is accepted it may be required to apply for a dedicated Opaque Type for the VLAN distribution LSA. The 24 bits of Opaque ID is VLAN distribution instance. This number is assigned by the originating router and unique within the context of that router. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opaque Type | VLAN distribution instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Opaque Type Identifies the VLAN distribution LSA. Suggested value is 129. VLAN distribution instance A 24-bit number assigned by the originating router. Unique within the originating router. 5. VLAN distribution TLV format The VLAN Distribution LSA payload is defined in form of TLV which is flexible enough to facilitate the introduction of new information as required. In addition the format detailed below allows nested TLVs and the ability to define sub TLVs 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value.. ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Defines VLAN information TLVs (NOTE: These TLV values are independent of the Opaque Type) Senevirathne Informational - March 2001 5 draft-tsenevir-8021qospf-00.txt October 2000 Length Length of the value field in bytes. Value Value of the TLV. The Value field is padded with zeros to the nearest 32 bit boundary. As an example, a 3 byte long Value field has a Length field of 3 and the last byte of the Value field is padded with zero. 6. Top Level TLV definitions There are several TLV defined at the top level. Each of these TLVs can possibly carry sub-TLVs. Domain ID TLV Mandatory Router ID TLV Mandatory BPDU TAG TLV Mandatory* VLAN Distribution TLV Mandatory Global Service TLV Optional * Mandatory only if the Spanning Tree Protocol is enabled on the advertising router for the VLAN domain scope identified in the Domain ID TLV sent in the same update. Otherwise this TLV should be omitted. 6.1. Domain ID TLV Unlike IP addresses, VLAN allocation is entirely a local policy and there is no global scope for a given VLAN Tag value. For example, router A and B can both have same VLAN V but they may not necessarily communicate or be related. To resolve this ambiguity, we define a VLAN domain. VLANs within a given VLAN domain scope are related. VLANs in different VLAN domains are considered mutually exclusive. We define the Domain ID TLV to carry VLAN domain information. The VLAN Domain ID is statically configured. It is assumed that there is an understanding of the Domain ID values between network administrators responsible for each VLAN domain when allocating those VLAN Domain IDs. The assignment of VLAN domain ID is entirely an administrative matter and considered beyond the scope of the discussion. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain ID | Senevirathne Informational - March 2001 6 draft-tsenevir-8021qospf-00.txt October 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Domain ID Type = 1 Length Length of the Domain ID, presently 4 bytes Domain ID A 32-bit number that defines the scope of VLAN domain 6.2. Router ID TLV The Router ID TLV advertises the router ID of the originating router. Other routers may use this as the end point IP address to reach this VLAN. Hence it may be advisable to select the router ID based on a loop back interface, instead of an interface IP address. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID - IPV4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type IP V4 Router ID = 2 Length Length of the Router ID field - 4 bytes Router ID End point router IP V4 address. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID - IPV6 | + + | | Senevirathne Informational - March 2001 7 draft-tsenevir-8021qospf-00.txt October 2000 + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type IP V6 Router ID = 3 Length Length of the Router ID field - 12 bytes Router ID End point router IP V6 address 6.3 BPDU TAG TLV The BPDU Tag TLV advertises the TAG that this Router expects in an incoming BPDU. If the 802.1D Spanning Tree Protocol is not enabled on the advertising router for the VLAN domain scope identified in the Domain ID TLV sent in the same update, then the BPDU TLV should not be advertised. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BPDU TAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type BPDU TAG TLV = 4 Length Length of the BPDU TAG TLV = 4 bytes Reserved Set to zero on transmission and ignored on reception BPDU TAG 12 Bit TAG for the BPDU for this domain 6.4 VLAN Distribution TLV Senevirathne Informational - March 2001 8 draft-tsenevir-8021qospf-00.txt October 2000 VLAN distribution TLV is the top level TLV that distributes several sub-TLVs that contain VLAN specific information. There are three sub-TLVs defined under the top level VLAN distribution TLV; VLAN TLV Mandatory Scope Label TLV Optional Service TLV Optional 6.4.1 Top level VLAN Distribution TLV format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value.. ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Top Level VLAN distribution TLV = 5 Length Length of the value field in bytes. Value Value of the TLV. This contains all the sub TLVs. All sub-TLVs are 32-bit aligned and hence the value field of this TLV is a multiple of 32-bit as well. 6.4.2 VLAN sub-TLV format VLAN sub-TLVs distribute VFEC entries; the distribution scope is defined by the Domain ID TLV. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved| F | Start VLAN TAG | End VLAN TAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved| F | SP | EP | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Senevirathne Informational - March 2001 9 draft-tsenevir-8021qospf-00.txt October 2000 VLAN sub-TLV = 1 Length Length of this TLV = 8 bytes M Matching Criteria. Conservative matching if M == 1 else Liberal matching. See [3] for definition of Liberal and conservative matching. Reserved All reserved fields are set to zero on transmission and ignored on receipt. F P bit Range Match - b'10 P bit Exact Match - b'11 Start VLAN TAG Starting TAG of this VFEC entry End VLAN TAG End TAG of the VFEC entry SP Starting value for P bits EP End value of P bits. This field is ignored if F == 11 6.4.3 Scope Label Sub-TLV Scope Label TLV distributes a locally significant label, which could be used as a hidden label. The Scope Label, may be used to provide a wider forwarding scope on top of the standard MPLS label. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Senevirathne Informational - March 2001 10 draft-tsenevir-8021qospf-00.txt October 2000 Type Scope Label Sub-TLV = 2 Length Length of this TLV = 4 bytes Reserved Set to zero on transmission and ignored on reception. Label Hidden Label. 20 bit MPLS label. 6.4.4. Service Sub-TLV Service Sub-TLV defines various services offered in this VLAN or group of VLANs. These services are specific to the corresponding VLAN(s) and supercede equivalent Domain Services if they exist or are specified (See below). Sub-TLV types 3 through 7 are allocated for "VLAN Services". Specifics regarding actual services are considered beyond the scope of this discussion. The purpose of this TLV is to provide a framework to allow distribution of such services. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3 - 7 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value.. ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Service Sub-TLV presently 3 to 7 Length Length of the Service Sub_TLV value Value Value of this TLV TBD 6.4.5 Encoding of the VLAN sub TLV Senevirathne Informational - March 2001 11 draft-tsenevir-8021qospf-00.txt October 2000 Encoding of nested sub-TLVs within the VLAN distribution TLV should conform to the following sequence. There must be at least one or more VLAN sub-TLV. Corresponding Scope Label TLVs, if present, should immediately follow the VLAN sub-TLV. If scope label TLV belongs to more than one VLAN sub-TLV, it should appear after all the corresponding VLAN sub- TLV. Service sub-TLV, if present should follow the Scope Label TLV. Service sub-TLV should follow the VLAN sub-TLV(s), if Scope Label TLV is not present. Presence of a new VLAN sub TLV ends the scope of the Service and Scope Label sub-TLVs. VLAN sub TLV that do not have Scope Label Sub-TLV and Service Sub- TLV must be encoded at the end. 7. Global Service TLV Global Service TLV allows the advertisement of various domain wide services. The types of the services advertised are implementation specific and beyond the scope of this document. However the following nested TLV format with separate sub-TLVs for each service or class of service is proposed. 7.1 Global Service TLV format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value.. ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Global Service TLV = 6 Length Length of the Global service TLV Value Contains nested sub-TLVs Senevirathne Informational - March 2001 12 draft-tsenevir-8021qospf-00.txt October 2000 7.2 Global Service TLV sub-Types Allocation and definition of Global Service sub-Types are open to discussion. At this point sub-Types 0-255 are reserved for private and experimental usage. However, if this proposal is accepted, it is suggested that values 0-127 are reserved for IANA allocation of well know services and 128-255 are for private and experimental usage. 8. Encoding of Top Level TLVs The first TLV in the VLAN distribution LSA payload MUST be the Router ID TLV. Otherwise it is considered an erroneous TLV and MUST be silently discarded. The Domain ID TLV defines the scope of the VLAN domain. It MUST be present and MUST immediately follow the Router ID TLV. If present, the BPDU TLV MUST immediately follow the Domain ID TLV. There MUST be at least one VLAN Distribution TLV. The VLAN Distribution TLV must immediately follow the BPDU TLV, if present, or Domain ID TLV if the BPDU TLV is not present. If present, the Scope Label TLV MUST immediately follow the VLAN Distribution TLV. If present, the Global Service TLV MUST immediately follow the Scope Label TLV. If the Scope Label TLV is not present, the Global Service TLV MUST immediately follow the VLAN Distribution TLV. Within a given VLAN Distribution LSA only information relating to a single VLAN domain may be encoded. Separate VLAN Distribution LSAs MUST be generated for each VLAN domain. Each of these LSAs has unique VLAN distribution instance (see section 4). Any VLAN Distribution LSA that violates the above rules MUST be silently discarded. They SHOULD not be flooded. At this point, it is suggested that only information relating to a single VLAN domain is included in a single LSA. However there is nothing in the TLV architecture presented here prevents multiple VLAN Domain encoding in single LSA. Exact format for the VLAN distribution LSA is open for discussion. 9. Processing of the VLAN Distribution LSA Only VLAN Distribution LSAs that belong to locally enabled VLAN domains are processed and update VFEC tables. LSAs that do not belong to the local domain may still be included in the Link State Database and MUST be flooded according to OSPF[5] conventions. Senevirathne Informational - March 2001 13 draft-tsenevir-8021qospf-00.txt October 2000 VLAN Distribution LSAs should NOT be included in SPF calculations. Any changes to VFEC tables should trigger LSA updates. In addition, all OSPF update events should trigger LSA updates. VFEC table population based on received LSAs is performed per VLAN domain. The exact procedures for updating VFEC entries from distributed VLAN information is implementation dependent. 10. Security Considerations This implementation does not affect the underlying security requirements of OSPF. Implementations that wish to implement higher levels of security should consider cryptographic OSPF [5]. 11. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Senevirathne, T and Billinghurst, P, "Use of CR-LDP or RSVP-TE to Extend 802.1Q Virtual LANs across MPLS Networks", Work in Progress, October 2000. 4 Coltun, R, "The OPSF Opaque LSA Option", Work in Progress, July 1998. 5 Moy, J., "OPSF Version 2", RFC 2328, April 1998. 12. Acknowledgments Ideas presented in this document have been influenced by sighted references and ongoing work in the IETF. Senevirathne Informational - March 2001 14 draft-tsenevir-8021qospf-00.txt October 2000 13. Author's Addresses Tissa Senevirathne Nortel Networks 4401 Great America Pkwy, Santa Clara, CA 95054 Phone: 408-565-2571 Email: tsenevir@nortelnetworks.com Paul Billinghurst Nortel Networks 4401 Great America Pkwy, Santa Clara, CA 95054 Phone: 408-565-2357 Emial: pbilling@nortelnetworks.com Senevirathne Informational - March 2001 15 draft-tsenevir-8021qospf-00.txt October 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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 Senevirathne Informational - March 2001 16