Internet Working Group Don Fedyk Internet Draft Nortel Expiration Date: March 2006 Yakov Rekhter Juniper Networks (Editors) October 2005 Layer 1 VPN Basic Mode draft-fedyk-l1vpn-basic-mode-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Abstract This draft describes the basic mode of Layer 1 VPNs (L1VPN BM) that is port based VPNs. In L1VPN BM, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port-topology. This draft defines the operational model using either provisioning or a VPN auto- discovery mechanism and the signaling extensions for the L1VPN BM. This draft uses BGP as an example of the auto-discovery mechanism. Fedyk, Rekhter [Page 1] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 Table of Contents 1. Introduction..................................................2 2. Layer 1 VPN Services..........................................3 3. Addressing, Ports, Links and Control Channels.................5 3.1 Service Provider Realm.......................................6 3.2 Layer 1 Ports and Index......................................6 3.3 Port and Index Mapping.......................................7 4. Port Based L1VPN Basic Mode...................................8 4.1 L1VPN Port Information Tables................................9 4.2 CE to CE LSP Establishment..................................10 4.3 Signaling...................................................11 4.3.1 Signaling Procedures......................................12 5. Security Considerations......................................14 6. IANA Considerations..........................................14 7. Intellectual Property Considerations.........................14 8. References...................................................15 8.1 Normative References........................................15 8.2 Informative References......................................15 9. Author's Addresses...........................................16 10. Disclaimer of Validity......................................17 11. Full Copyright Statement....................................17 1. Introduction In this document, we consider a service provider network that consists of devices that support GMPLS (e.g., Lambda Switch Capable devices, Optical Cross Connect, SDH Cross Connect, etc.). We partition these devices into P (provider) and PE (provider edge) devices. In the context of this document we'll refer to the former devices as just "P", and to the latter devices as just "PE". The Ps are connected only to the devices within the provider's network. The PEs are connected to the other devices within the provider network (either Ps, or PEs), as well as to the devices outside of the provider network. We'll refer to such other devices as Client Edge Devices (CEs). An example of a CE would be a router, an SDH cross-connect, or an Ethernet switch. The [GMPLS-OVERLAY] draft is the basis for signaling from the CE to the PE. In the [GMPLS-OVERLAY] draft the terms Core Node (CN) and Edge Node (EN) correspond to PE and CE respectively. Fedyk & Rekhter. [Page 2] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 +---+ +---+ | P | | P | +---+ +---+ PE / \ PE +-----+ +-----+ +--+ | | | |----| | +--+ | | | | |CE| |CE|----+-----+ | |----| | +--+\ | | | +--+ \ +-----+ | | \ | | | | +--+ \| | | |----|CE| +-----+ +-----+ +--+ \ / +---+ +---+ | P |....| P | +---+ +---+ Figure 1: Generalized Layer 1 VPN Reference Model This draft specifies how the L1VPN Basic Mode (BM) service can be realized using VPN auto-discovery and Generalized Multi- Protocol Label Switching (GMPLS)Signaling [GMPLS-RSVP-TE], Routing [GMPLS-Routing] and LMP [GMPLS-LMP] mechanisms. The L1VPN auto-discovery has similar requirements to the L3VPNs auto-discovery [L3VPN-REQ]. As with L3VPNs there are protocol options to be made with auto-discovery. For illustration purposes BGP is used as a protocol example but other protocols or methods of VPN distribution may be equally well suited. GMPLS routing and signaling are used without extensions within the provider network to establish and maintain Lambda Switch Capable (LSC) or SONET/SDH (TDM) connections between provider nodes. This follows the model in [GMPLS-Overlay]. LMP can be used to automate link discovery and augment routing as well as failure handling capabilities. 2. Layer 1 VPN Services Layer 1 services on the interfaces of customer and provider ports could be any of the L1 interfaces supported by GMPLS. Since the mechanisms specified here use GMPLS as the signaling mechanism, and since GMPLS applies to both SONET/SDH (TDM) and Lambda Switch Capable (LSC) interfaces, it results that L1VPN services includes but is not restricted to Lambda Switch Capable or TDM based equipment. Note that this document describes Basic Mode L1 VPNs and as such assumes that (1) GMPLS RSVP-TE is used for signaling both within the service provider (between PEs), as well as between the customer and the service provider (between CE and PE); (2) GMPLS RSVP-TE is used not just as a signaling mechanism, but also as a routing mechanism within the provider network. Basic Mode L1 VPNs do not assume Fedyk & Rekhter. [Page 3] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 for GMPLS Routing on the CE-PE link since outside the scope of a basic mode of operation. A CE is connected to a PE via one or more links. In the context of this document a link is the same as a GMPLS Traffic Engineering (TE) link construct, as defined in [GMPLS-ROUTING]. In the context of this document a link is a logical construct that is a member of a VPN hence introducing the notion of membership to a set of CEs forming the VPN. Interfaces at the end of each link could be any of the interfaces that are supported by GMPLS. Likewise, CEs and PEs could be any devices that are supported by GMPLS (e.g., optical cross connects, SDH cross-connects, LSRs, etc). Each link may consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot respectively). For the purpose of this discussion we assume that all the channels within a given link have shared similar characteristics (e.g., switching capabilities, encoding, type, etc_), and can be selected independently from the CE's point of view. Channels on different links of a CE need not have the same characteristics. There may be more than one link between a given CE PE pair. A CE may be connected to more than one PE (with at least one port per each PE). And, of course, a PE may have more than one CE from different VPNs connected to it. If a CE is connected to a PE via multiple links and all these links belong to the same VPN, then for the purpose of this document these links could be treated as a single link using the link bundling constructs [LINK-BUNDLING]. A link may have only data bearing channels, or only control bearing channels, or both. For the purpose of this discussion we assume that for a given CE-PE pair at least one of the links between them has at least one data bearing channel, and at least one control bearing channel, or there is IP reachbility between the CE and the PE that could be used to exchange control information. A point-to-point link has two end-points - one on the CE and one on the PE. In the context of this document we'll refer to the former as "CE port", and to the latter as "PE port". From the above it follows that a CE is connected to a PE via one or more ports, where each port may consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot respectively), and all the channels within a given port have shared similar characteristics (e.g., capabilities, encoding, etc_), and can be interchanged from the CEs point of view. Just like links, in the context of this document, ports are logical construct that are used to represent grouping of physical Fedyk & Rekhter. [Page 4] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 resources on a per L1VPN basis that are used to connect a CE to a PE. At any given point in time, a given port on a PE is associated with at most one L1VPN, or to be more precise with at most one Port Information Table maintained by the PE (although different ports on a given PE could be associated with different L1VPNs, or to be more precise with different Port Information Tables). The association of a port with a VPN may defined by provisioning the relationship on the provider devices. In other words the context of a VPN membership in Basic mode is enforced by service provider control. This document assumes that the interface between the CE and PE used for the purpose of signaling is capable to initiate/process GMPLS protocols messages [GMPLS-RSVP-TE] and follows the procedures described in [GMPLS-OVERLAY]. An important goal of L1VPN services (particularly with respect to basic mode services) is the ability to support what is known as "single end provisioning", where the addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port. The extension of this model to the CE is outside the scope of the L1VPN BM. In L1VPN BM a CE device could be provisioned with the corresponding port information in much the same manner an overlay service is provisioned today. Another important goal in the L1VPN service is the ability to establish/terminate an LSP between a pair of (existing) ports within a L1VPN from the CE devices without involving configuration changes in any of the provider's devices. In other words, the VPN topology is under the CE device control. The mechanisms outlined in this document aim at achieving these above goals. Specifically, as part of the L1VPN service offering, these mechanisms (1) enable the service provider to restrict the set of ports to which a given port could be connected, (2) enable a CE to establish the actual LSP to a subset of ports. Finally, the mechanisms allow arbitrary L1VPN topologies to be supported ranging from hub-and-spoke to full mesh point to point connections. Other more advanced service and topology support such as point to multi point (P2MP) services etc. is for further study. The L1VPN BM draft does not specify the exchange of CE routing or topology information to the provider. This type of information is not precluded from the architecture but is beyond the scope of this document. 3. Addressing, Ports, Links and Control Channels Fedyk & Rekhter. [Page 5] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 GMPLS established conventions for Addressing and link numbering are discussed in the [GMPLS-Arch] documents. This section builds on those definitions for the L1VPN case where we now have Customer and Provider addresses in a Layer 1 Context. 3.1 Service Provider Realm This document assumes that a service provider, or a group of service providers that collectively offer L1VPN service, have a single addressing realm that spans all PE devices involved in providing the L1VPN service. This is necessary to enable GMPLS mechanisms for path establishment and maintenance. We will refer to this realm as the service provider addressing realm. This document further assumes that each L1VPN customer has its own addressing realm. We will refer to such realms as the customer addressing realms. Customer addressing realms may overlap with each other, and may also overlap with the service provider addressing realm. 3.2 Layer 1 Ports and Index Within a given L1VPN each port on a CE that connects the CE to a PE has an identifier that is unique within that L1VPN (but need not be unique across several L1VPNs). One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN, and use this address as a port identifier. Another way to construct such an identifier is to assigned each port on a CE an index that is unique within that CE, assign each CE an address that is unique within a given L1VPN, and then use a tuple as a port identifier. Note that both the port and the CE address may be an address in several formats. This includes, but not limited to IPv4, IPv6, and NSAP. Note that NSAP addresses may be carried in IPv6 Fields as specified in [NSAP-IPv6]. This identifier is part of the Customer Addressing Realm and is used by the CE device to identify the CE port and the CE remote port for signaling. CEs do not know or understand the Provider Realm addresses. Within a service provider network, each port on a PE that connects that PE to a CE has an identifier that is unique within that network. One way to construct such an identifier is to assign each port on a PE an index that is unique within that PE, assign each PE an IP address that is unique within the service provider addressing realm, and then use a tuple as a port identifier within the provider network. Another way to construct such an identifier is to assign an IP address that is unique within the service provider addressing realm to each such port. Either way, this IP address is internal to the service provider network and is used for GMPLS signaling within the service provider network. Fedyk & Rekhter. [Page 6] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 As a result, each link connecting the CE to the PE is associated with a CE port that has a unique identifier within a given L1VPN, and with a PE port that has a unique identifier within the service provider network. We'll refer to the former as the customer port identifier (CPI), and to the latter as the provider port identifier (PPI). 3.3 Port and Index Mapping This document assumes that each PE port that has a PPI also has an identifier that is unique within the L1VPN customer addressing realm of the L1VPN associated with that port. One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN customer addressing realm, and use this address as a port identifier. Another way to construct such an identifier is to assign each port an index that is unique within a given PE, assign each PE an IP address that is unique within a given L1VPN customer addressing realm (but need not be unique within the service provider network), and then use a tuple that acts as a port identifier. We'll refer to such port identifier as the VPN-PPI. For L1VPNs it is a requirement that provider operations are independent of the VPN customers addressing realm and the provider addressing realm is hidden from the customer. To achieve this we have created two identifies, one customer facing and the other provider facing. The PE IP address used for the VPN-PPI is independent of the PE IP address used for the PPI (as the two are taken from different address realms, the former from the provider's addressing realm and the latter from a VPN customer's addressing realm). If for a given port on a PE, the PPI and the VPN-PPI are both unnumbered, then they both could use exactly the same port index. This is a mere convenience since the PPI and VPN_PPI can be in any combination of valid formats. +----+ +----+ | | | | | |CPI VPN-PPI | | ---| CE |-----------------------------| PE |--- | | | | | | PPI | | +----+ +----+ (Provider realm) Figure 2: Customer/Provider Port/Index Mapping Note, as stated earlier, that IP addresses used for the CPIs, PPIs and VPN-PPIs could be either IPv4, IPv6 or NSAP addresses. Fedyk & Rekhter. [Page 7] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 For a given link connecting a CE to a PE, if the CPI is an IP address, then the VPN-PPI has to be an IP address as well. And if the CPI is an , then the VPN-PPI must be a . However, for a given port on PE, whether the VPN-PPI of that port is an IP address or a is independent of whether the PPI of that port is an IP address or a . This document assumes that assignment of the PPIs is controlled solely by the service provider (without any coordination with the L1VPN customers), while assignment of addresses used by the CPIs and VPN-PPIs is controlled solely by the administrators of L1VPN . The L1VPN administrator is the entity that controls the L1VPN service specifics for the L1VPN customers. This function may be owned by the service provider but may also be performed by a third party who has agreements with the service provider. And, of course, each L1VPN could assign such addresses on its own, without any coordination with other L1VPNs. This document also assumes that there is an IP control channel between the CE and the PE. This channel could be either a single IP hop, or a tunnel (GRE or IP-in-IP) or an IP private network, or even an IP VPN for example. We'll refer to the CE's address of this channel as the CE Control Channel Address (CE-CC-Addr), and to the PE's address of this channel as the PE Control Channel Address (PE-CC-Addr). Both CE-CC-Addr and PE-CC-Addr are required to be unique within the L1VPN they belong to, but are not required to be unique across multiple L1VPNs. Control channel addresses are not shared amongst multiple VPNs. Assignment of CE-CC-Addr and PE-CC-Addr are controlled by the administrators of the L1VPN. Multiple ports on a CE could share the same control channel only as long as all these ports belong to the same L1VPN. Likewise, multiple ports on a PE could share the same control channel only as long as all these ports belong to the same L1VPN. 4. Port Based L1VPN Basic Mode An L1VPN is a port-based VPN service where a pair of CEs could be connected through the service provider network via a GMPLS- based LSP within a given VPN port topology. It is precisely this LSP that forms the basic unit of the L1VPN service that the service provider network offers. If a port by which a CE is connected to a PE consists of multiple channels (e.g., multiple wavelengths), the CE could establish LSPs to multiple other CEs over this single port. In the L1VPN, the service provider does not initiate the creation of an LSP between a pair of PE ports. This is done Fedyk & Rekhter. [Page 8] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 rather by the CEs, which attach to the ports. However, the SP, by using the mechanisms/toolkit outlined in this document, restricts the set of other PE ports, which may be the remote endpoints of LSPs that have the given port as the local endpoint. Subject to these restrictions, the CE-to-CE connectivity is under the control of the CEs themselves. In other words, the SP allows a L1VPN to have a certain set of topologies (expressed as a port-to-port connectivity matrix; CE-initiated signaling is used to choose a particular topology from that set. For each L1VPN that has at least one port on a given PE, the PE maintains a port information table (PIT) associated with that L1VPN. A PIT contains a list of tuples for all the ports within its L1VPN. In addition, for local PE ports of a given L1VPN the tuples also include the VPN-PPIs of these ports. PE PE +---------+ +--------------+ +--------+ | +------+| | +----------+ | +--------+ | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | | CE1 |--| |PIT || BGP route | | PIT | |-| CE2 | +--------+ | | ||<----------->| | | | +--------+ | +------+| Distribution| +----------+ | | | | | +--------+ | +------+| | +----------+ | +--------+ | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B | | CE1 |--| |PIT ||--( GMPLS )-| | PIT | |-| CE2 | +--------+ | | || (Backbone ) | | | | +--------+ | +------+| --------- | +----------+ | | | | | +--------+ | +-----+ | | +----------+ | +--------+ | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | | CE1 |--| |PIT | | | | PIT | |-| CE2 | +--------+ | | | | | | | | +--------+ | +-----+ | | +----------+ | +---------+ +--------------+ Figure 3 Basic Mode L1VPN Service 4.1 L1VPN Port Information Tables A PIT may be populated entirely by provisioning. This allows the PE to PE ports to be connected on demand. This means that the table entries are provisioned either on each PE box for each corresponding L1VPN or on a provisioning system in the provider control. This may or may not mean that CE addresses are entered multiple times on multiple PEs. As the network grows some form of automation is desirable. Fedyk & Rekhter. [Page 9] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 The PIT is by nature VPN-specific in that entries for a L1VPN are only required on a PE if that PE locally supports that L1VPN by having CEs belonging to that VPN attached to the PE. However, the full set of PITs with all L1VPN entries for multiple VPNs may also be available to all PEs. Another option is to have an auto-discovery mechanism; for example BGP Auto-discovery could be modified for L1VPN. L1VPN auto-discovery has the advantage of reducing the configuration for L1VPNs which could be desirable in large VPNs. A PIT on a given PE is populated from two sources: 1. The information related to the CEs' ports attached to the ports on that PE (this information could be optionally received from the CEs, however in Basic Mode we assume this information is provisioned.) Beyond Basic Mode this information could be discovered by several mechanism such as LMP, IGPs or BGP. 2. The information received from other PEs. This is the information that is auto-discovered within the Provider Network. We'll refer to the former as the "local" information, and to the latter as the "remote" information. A way to propagate this local information to other PEs is by using BGP VPN auto-discovery procedures, as specified in [BGP- VPN-AUTODISCOVERY]. In this case to restrict the flow of this information to only the PITs within a given L1VPN, we use BGP route filtering based on the Route Target Extended Community [BGP-COMM], as follows: Each PIT on a PE is configured with one or more Route Target Communities, called "Export Route Targets" that are used to tag the local information when it is exported into provider's BGP. The granularity of such tagging could be as fine as a single pair. In addition, each PIT on a PE is configured with one or more Route Target Communities, called "Import Route Targets". Import Route Targets restrict the set of routes that could be imported from the provider's BGP into the PIT to only those routes that include at least one of these Communities. When a service provider adds a new L1VPN port to a particular PE, this port is associated at provisioning time with a PIT on that PE, and this PIT is associated (again at provisioning time) with that L1VPN. For the purpose of L1VPN BM the CE only knows the local CPI addresses and the remote CPI Addresses. 4.2 CE to CE LSP Establishment Fedyk & Rekhter. [Page 10] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 In order to establish an LSP, a CE needs to identify all other CEs in the CE's L1VPN it wants to connect to. A CE may already have obtained this information through provisioning or through some other schemes (such schemes are outside the scope of this document). Ports associated with a given CE-PE link, in addition to their CPI and PPI may also have other information associated with them that describes characteristics and constraints of the channels within these ports, such as encoding supported by the channels, bandwidth of a channel, total unreserved bandwidth within the port, etc. This information could be further augmented with the information about certain capabilities of the Service Provider network (e.g., support RSOH DCC transparency, arbitrary concatenation, etc.). This information is used to ensure that ports at each end of an LSP have compatible characteristics, and that there are sufficient unallocated resources to establish an LSP between these ports. It may happen that for a given pair of ports within an L1VPN, each of the CEs connected to these ports would concurrently try to establish an LSP to the other CE. If having a pair of LSPs between a pair of ports is viewed as undesirable, the way to resolve this is to require the CE with the lower value of the CPI to terminate the LSP originated by the CE. This option could be controlled by configuration on the CE devices. 4.3 Signaling In L1VPN BM a CE needs to be configured with the CPIs of other ports. Once a CE is configured with the CPIs of the other ports within the same L1VPN, which we'll refer to as "target ports", the CE uses a (subset of) GMPLS signaling, to request the provider network to establish an LSP to a target port. For inter-CE connectivity, the request originated by the CE contains the CPI of the port on the CE that CE wants to use for the LSP, and the CPI of the target port. When the PE attached to the CE that originated the request receives the request, the PE identifies the appropriate PIT, and then uses the information in that PIT to find out the PPI associated with the CPI of the target port carried in the request. The PPI should be sufficient for the PE to establish an LSP. Ultimately the request reaches the CE associated with the target CPI (note that the request still carries the CPI of the CE that originated the request). If the CE associated with the target CPI accepts the request, the LSP is established. Note that a CE need not establish an LSP to every target port that CE knows about - it is a local CE matter to select a Fedyk & Rekhter. [Page 11] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 subset of target ports to which the CE will try to establish LSPs. The procedures for establishing an individual connection between two corresponding CEs is the same as the procedure specified for GMPLS overlay. [GMPLS-OVERLAY] 4.3.1 Signaling Procedures When a CE sends an RSVP Path message to a PE, the source IP address in the IP packet that carries the message is set to the appropriate CE-CC-Addr, and the destination IP address in the packet is set to the appropriate PE-CC-Addr. When the PE sends back to the CE the corresponding Resv message, the source IP address in the IP packet that carries the message is set to the PE-CC-Addr, and the destination IP address is set to the CE-CC- Addr. Likewise, when a PE sends an RSVP Path message to a CE, the source IP address in the IP packet that carries the message is set to the appropriate PE-CC-Addr, and the destination IP address in the packet is set to the appropriate CE-CC-Addr. When the CE sends back to the PE the corresponding Resv message, the source IP address in the IP packet that carries the message is set to the CE-CC-Addr, and the destination IP address is set to the PE-CC-Addr. In addition to being used for IP addresses in the IP packet that carries RSVP messages between CE and PE, CE-CC-Addr and PE-CC-Addr are also used in the Next/Previous Hop Address field of the IF_ID RSVP_HOP object that is carried between CEs and PEs. In the case where a link between CE and PE is a numbered non- bundled link, the CPI and VPN-PPI of that link are used for the Type 1 or 2 TLVs of the IF_ID RSVP HOP object that is carried between the CE and PE. In the case where a link between CE and PE is an unnumbered non-bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLV. In the case where a link between CE and PE is a bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLVs. When a CE originates a Path message to establish an LSP from a particular port on that CE to a particular target port the CE uses the CPI of its port in the Sender Template object. If the CPI of the target port is an IP address, then the CE uses it in the Session object. And if the CPI of the target port is a tuple, then the CE uses the IP address part of the tuple in the Session object, and the whole tuple as the Unnumbered Interface ID subobject in the ERO. When the Path message arrives at the ingress PE, the PE selects the PIT Fedyk & Rekhter. [Page 12] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 associated with the L1VPN, and then uses this PIT to map CPIs carried in the Session and the Sender Template objects to the appropriate PPIs. Once the mapping is done, the ingress PE replaces CPIs with these PPIs. As a result, the Session and the Sender Template objects that are carried in the GMPLS signaling within the service provider network carry PPIs, and not CPIs. At the egress PE, the PE performs the reverse mapping - it maps PPIs carried in the Session and the Sender Template object into the appropriate CPIs, and then sends the Path message to the CE that has the target port. At the egress PE, the reverse mapping operation is performed. The PE extracts the ingress/egress PPI values carried in the SENDER_TEMPLATE and SESSION objects (respectively). The egress PE identifies the appropriate PIT to find out the appropriate CPI associated with the PPI of the egress CE. Once the mapping is retrieved, the egress PE replaces the ingress/egress PPI values with the corresponding CPI values. As a result, the SESSION and the SENDER_TEMPLATE objects included in the GMPLS RSVP-TE Path message sent from the egress PE to the egress CE carry CPIs, and not PPIs. Here also, for the GMPLS RSVP-TE Path messages sent from the egress PE to CE, the source IP address (of the IP packet carrying this message) is set to the appropriate PE-CC-Addr, and the destination IP address (of the IP packet carrying this message) is set to the appropriate CE- CC-Addr. When the Path message reaches the egress CE, and gets processed, the latter initiates towards the egress PE the exchange of the Resv message. Here, the FILTER_SPEC object is process similarly to the SENDER_TEMPLATE object. Both egress and ingress PE (in sequence), performs the same mapping operation as with the corresponding Path message. Once the Resv message reaches the ingress CE, the switched connection is established. An ingress PE may receive and potentially reject a Path message that contains ERO (Explicit Route Object), or ERO and so cause the switched connection setup to fail. However, the ingress PE may accept EROs, which include a sequence of []. - Path message without ERO: when an ingress PE receives a Path message from an ingress CE that contains no ERO, it MUST calculate a route to the destination for the PE-to-PE LSP and include that route in a ERO, before forwarding the Path message. One exception would be if the egress core node were also adjacent to this core node. - Path message with ERO: when an ingress PE receives a Path message from an ingress CE that contains an ERO (of the form detailed above), the former computes a path to reach to reach the egress PE. It then inserts this path as part of the ERO before forwarding the Path message. Fedyk & Rekhter. [Page 13] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 An ingress or an egress PE may include an RECORD_ROUTE object and remove/filter the RRO from the received Path message before forwarding it. Further an egress or an ingress PE may remove/filter the RRO from a Resv message before forwarding it. Filtering a RRO consist in editing its content and include only the subobjects based on a local or global policy. This allows the ingress/egress CE to be aware of the selected link and labels on the egress/ingress CE side, respectively, for the switched connections constituting this L1VPN. The exact format of the extensions is TBD in a future revision. 5. Security Considerations Since association of a particular port with a particular L1VPN (or to be more precise with a particular PIT) is done by the service provider as part of the service provisioning process (and thus can't be altered via signaling between CE and PE), and since signaling between CE and PE is assumed to be over a private network (and thus can't be spoofed by entities outside the private network), the solution described in this document doesn't require authentication in signaling. 6. IANA Considerations This document makes no requests for IANA action. 7. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be Fedyk & Rekhter. [Page 14] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 8. References 8.1 Normative References [L1VPN-REQ] Ould-Brahim, H., Rekhter, Y., et al., "Service Requirements for Optical Virtual Private Networks", work in progress. [GMPLS-OVERLAY] Swallow, G., et al., "Generalized Multiprotocol Label Switching(GMPLS)User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", work in progress. 8.2 Informative References [GMPLS-SIGNALING] Berger, L. (editor), "Generalized MPLS - Signaling Functional Description", January 2003, RFC3471. [GMPLS-RSVP-TE] Berger, L. (editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC3473, January 2003. [GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions in Support of Generalized MPLS", work in progress [GMPLS-HIERARCHY] Kompella, K., Rekhter, Y., "LSP Hierarchy with Generalized MPLS TE", work in progress. [GMPLS-ARCH] Mannie, E. (Editor), "Generalized Multi-protocol Label Switching Architecture," RFC3945, October 2004. [LINK-BUNDLING] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS Traffic Engineering", work in progress. [BGP-VPN-AUTODISCOVERY] Ould-Brahim, H., Rosen, E., Rekhter, Y., "Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn-auto-05.txt, work in progress [GMPLS-LMP] J.P.Lang (Editor), "Link Management Protocol," draft-ietf-ccamp-lmp-10.txt, October 2003. [NSAP-IPV6] Carpenter, B. et al., "OSI NSAPs and IPv6", RFC 1888, August 1996. [L3VPN-REQ] A. Nagarajan, "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)" RFC 3809, June 2004. Fedyk & Rekhter. [Page 15] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 9. Acknowledgments The authors would like to thank Adrian Farrel, Hamid Ould- Brahim for their valuable comments. 9. Author's Addresses Don Fedyk Nortel Networks 600 Technology Park Billerica, Massachusetts 01821 U.S.A Phone: +1 (978) 288 3041 Email: dwfedyk2nortelnetworks.com Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 Email: yakov@juniper.net Dimitri Papadimitriou (Alcatel) Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be Richard Rabbat Fujitsu 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085 Email: richard@us.fujitsu.com Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102 Phone: +1 703 847-1801 Email: lberger@movaz.com Fedyk & Rekhter. [Page 16] Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005 10. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Fedyk & Rekhter. [Page 17]