Network Working Group Tissa Senevirathne Internet Draft Document: draft-tsenevir-sig-nsp-00.txt August 2003 Category: Informational Expires : February 2004 Architecture for Generic NSP Layer related Signaling and Case Study: Use of L2TPv3 Extensions for VPLS signaling Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 obsolete 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 1. Abstract In this document, required architecture to support NSP Layer related signaling is presented. Generic NSP layer attributes presented here can be used over variety of signaling protocols. As an example, L2TPv3 can provide a new message and base AVP that, NSP applications can use to encompass NSP specific AVPs. Also, use of new NSP Layer attribute over L2TPv3 for VPLS related signaling is presented, as a case study. Senevirathne Informational 1 draft-tsenevir-sig-nsp-00.txt August 2003 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 PWE3 Architecture [3], present Native Service Processing (NSP) layer as the layer that specifies various applications such as VPLS and VPN. Signaling protocols such as L2TPV3 [4] present required signaling extensions to setup and maintain tunnels. Accompanying publications such as [5] present setting up tunnels to emulate various media types. As of the current practice, NSP layer messaging and signaling definitions are tightly coupled with the base signaling protocol. In this document we propose a generic message and signaling architecture, that is independent of the underlying signaling protocol. This document present, as a case study, required L2TPv3 signaling extensions for VPLS. It is expected these information to be moved to a separate document in future point of time. 3. Requirements The base signaling protocol MUST have capabilities to uniquely identify NSP Layer related messages and pass to the application layer. The base signaling protocol MUST have capabilities to encompass NSP Layer related messages in the payload. 4. Architecture We propose to define a single message called "NSP Layer" at the top level of the base signaling protocol, and define basic operations associated with the "NSP Layer" message. The three basic operations are: NSP-ADD, NSP-DELETE, NSP-ACK. Additional operations MAY be defined as required by applications. Message payload or the value field of the NSP Layer message carry, yet another set of AVP that specifies NSP layer specific operations. NSP applications specific attributes can be defined in a separate document. NSP Layer message can be carried over different base signaling protocols, such as L2TPv3, LDP, BGP-MP. Each of the applicable base signaling protocols are only required to define a single message type for "NSP Layer". NSP Layer specific messages are embedded in the message pay load and opaque to the signaling Senevirathne Informational 2 draft-tsenevir-sig-nsp-00.txt August 2003 protocol. Hence, it is anticipated, NSP application does not require major changes to adopt different signaling protocols. First attribute in the NSP Layer message MUST uniquely identify the semantics of the rest of the message. Hence, we propose , first attribute of the NSP Layer message to identify the NSP Type. Presently there are two NSP types defined, namely, VPLS and VPN. 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(NSP Type)| Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . + . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig 1: NSP-Type Description This MUST be the first attribute in the value field of the NSP-Layer attribute in L2TP control messages. If NSP-Type is unknown, call MUST be terminated. Type = 1 Length = 2 Value 1 - VPLS 2 - VPN 65535 - 32768 - Experimental Other values - Reserved and considered unknown. 4.1 Request-Response Model Some NSP applications may require explicit acknowledgment or response to certain or all messages. In such event NSP application message extensions SHOULD have ability to accomplish the requirements without requiring additional changes to base layer signaling protocols. Senevirathne Informational 3 draft-tsenevir-sig-nsp-00.txt August 2003 We propose to implement a Request-Response model. NSP Layer may need capabilities to implement some operations using uni-directional messaging and others operations using Request-Response model. In uni-directional messaging, NSP layer send a single message to the remote PE and does not expect an explicit response. In the Request- Response model, PE expect an explicit Response from the remote PE. One possible method to implement the above requirement is to have a NSP Layer attribute that clearly differentiate between messages that need a response and messages that does not need a response. 4.2 Error Recovery NSP application MUST have methods define to handle various error conditions associated with NSP Layer signaling, such as time out of a Response. Exact implementation details of error recovery is application and configuration dependent, and out side the scope of this document. 5. VPLS signaling messages This section define VPLS specific attributes. These attributes MUST be encapsulated within value field of the NSP Layer attribute.Attributes presented in this section MUST NOT be the first attribute in the NSP Layer message (value field of the NSP Layer attribute). First attribute MUST be NSP-TYPE. 5.0.1 VPLS-VPN-Address Description VPLS-VPN-address specifies the VPLS domain identifier for VPLS. Type 2 Length = 4 (TBD based on VPN address format) Value - VPN address 5.0.2 VPLS-VLAN-Identifier Description VPLS-VLAN-Identifier specifies the VLAN. Within a given VPLS domain there can be one or more VLAN. Call MUST be terminated if the value field contain reserved values. Type = 3 Length = 2 Senevirathne Informational 4 draft-tsenevir-sig-nsp-00.txt August 2003 Value 0 - 4k All other values reserved. 5.0.3 VPLS-Operation Description VPLS-Operation specifies the required operation. Call MUST bee terminated if the value field contain reserved values. Type = 4 Length = 2 Value 0 - VPLS-ADD 1 - VPLS-WITHDRAW 2 - VLAN-ADD 3 - VLAN-WITHDRAW 4 - RESPONSE (see NOTE below) All other values reserved. All other values reserved. NOTE: If a RESPONSE was received for a message that did not request a response, the response message should be silently discarded. 5.0.4 VPLS-Status Description VPLS-Status indicates the status notified by the message. This attribute MUST be present only in NSP-ACK message Type = 4 Length = 2 Value 0 - SUCCESS 1 - ERROR 2 - Unknown-attribute All other values reserved. All other values reserved. Senevirathne Informational 5 draft-tsenevir-sig-nsp-00.txt August 2003 5.0.5 VPLS-sequence Description VPLS-sequence attribute has 16 bit unsigned integer as the value. VPLS-sequence attribute SHOULD be used to identify applicable NSP- ACK messages, if asynchronous messaging is used between NSP layers. Type = 4 Length = 2 Value - Unsigned 16 bit integer. 5.0.5 VPLS-Request-Response Description VPLS-Request-Response attribute denotes whether an explicit response is required for the message. This attribute is optional. When the attribute is not used, remote device MUST consider it as a message that does not require an explicit Response. Type = 5 Length = 2 Value - 0 - No Response 1 - Response all other values reserved. A response MUST be generated with error code of unknown attribute. 6. L2TPv3 Extensions In this section we define L2TPv3 extensions to support and manage different NSP functionalities. Instead of defining separate attribute for each NSP type, we propose to define a single L2TPv3 attribute NSP Layer (AVP-TBA) for the entire NSP Layer. We propose the value field of "NSP Layer" attribute to contain another set of Attribute, Value Pairs that define the semantics and operations specific to the given NSP. We propose to define a new L2TPv3 Message Types, NSP (TBA-17). NSP Layer related signaling will be carried in this L2TPv3 messages. In this document, value field of "NSP Layer" is referred as NSP Layer message. Senevirathne Informational 6 draft-tsenevir-sig-nsp-00.txt August 2003 "NSP Layer" attribute MUST be send with M bit set [4]. Implementations, MAY choose to hide the information. Operation of H[4] bit is implementation specific and derived by the local policies and considered out of the scope of this document. Signaling information related to different NSP applications can be carried in the value field of NSP Layer attribute. MPLS, VPLS, VPWS are some of such commonly used NSP applications. 6.1 L2TP operation for VPLS L2TP signaling associated with VPLS can be arranged to several layers as follows Session Creation/Deletion Creation/Deletion of VPLS Addition/Removal VLAN from VPLS A given VPLS domain can have one or more VLANS. These additions and deletions can happen after the VPLS creation. In this section we are presenting a messaging example using Request- Response model. Message sequence chart VPLS Local PE Remote PE VPLS | | (1) Create -----> | ------> ICRQ | | | | ICRP <----- | | | | ------> ICCN | | | | | (2) NSP--(a)----> | ---(a)--->NSP | ---(a)--> NSP | | (2.1)NSP<---- | NSP <----- | <------ NSP (Response) | | | | | | (3) NSP--(b)---> | ---(b)-->NSP | --(b)---> NSP | | (3.1) NSP<----- | NSP<---- | <------ NSP (Response) | | | | | | Disconnect-----> -----> CDN | ------> Disconnect Senevirathne Informational 7 draft-tsenevir-sig-nsp-00.txt August 2003 (1) Create the session (2) Signal to create the VPLS (NSP) and (2.1) Bind VPLS instance to session created at (1). (3) Signal to delete the VPLS (NSP), (3.1) Unbind the VPLS from session. (4) Delete the session (a) Message has VPLS-Operation attribute set to ADD. Hence effectively translating the semantics of the message to VPLS-ADD (b) Message has VPLS-Operation attribute set to DELETE. Hence effectively translating the semantics of the message to VPLS-DELETE Following AVP MUST be present in the NSP Message Message Type (NSP) Local Session ID Remote Session ID NSP Layer NSP Layer value field MUST contain following NSP specific attributes upon Requesting and operation NSP-TYPE VPLS-Operation VPLS-Sequence VPLS-VPN-address and/or VPLS-VLAN-Identifier (zero or more, separate attribute for each VLAN) NSP Layer value field MAY contain following NSP specific attributes upon Requeesting and operation VPLS-Request-Response NSP Layer value field MUST contain following attributes for messages geenerated in response to a request. NSP-TYPE VPLS-VPN-Address VPLS-Status VPLS-Sequence VPLS-Operation (set to Response) 6.1.1 Adding a PE to the VPLS domain Senevirathne Informational 8 draft-tsenevir-sig-nsp-00.txt August 2003 Send standard ICRQ message to create the session NOTE: ICRQ message MUST contain additional attributes required by the [4]. Send NSP message with NSP Layer attribute. NSP Layer message MUST have NSP Type attribute set to VPLS. VPLS-VPN-address and VPLS- Operation and VPLS-sequence attributes MUST be present. VPLS- Request-Response attribute SHOULD be present. VPLS-Request-Response attribute MAY be set to Response. Additionally VPLS-VLAN-Identifier attribute MAY be present for each VLAN of the VPLS domain that the PE is member of. 6.1.2 Removing a PE from VPLS domain. Send NSP message with NSP Layer attribute. NSP Layer message MUST have NSP Type set to VPLS. VPLS-VPN-address and VPLS-Operation and VPLS-Sequence attributes MUST be present. VPLS-Request-Response attribute SHOULD be present. VPLS-Request-Response attribute MAY be set to Response. Additionally VPLS-VLAN-Identifier attribute MUST be present for each VLAN of the VPLS domain that the PE is member of and now wish to remove. Send standard CDN message to remove the session. NOTE: CDN message MUST contain attributes required by the [4]. 6.1.3 Adding a VLAN to the VPLS domain PE send NSP message with NSP-Layer attribute present. NSP-Layer message MUST contain, VPLS-VLAN-Identifier (one or more), VPLS- Operation and VPLS-Sequence and VPLS-VPN-address attributes. VPLS- Request-Response attribute SHOULD be present. VPLS-Request-Response attribute MAY be set to Response. 6.1.4 Removing a VLAN from the VPLS domain PE send NSP message with NSP-Layer attribute present. NSP-Layer message MUST contain, VPLS-VLAN-Identifier, VPLS-Operation and VPLS- Sequence and VPLS-VPN-address attributes. VPLS-Request-Response attribute SHOULD be present. VPLS-Request-Response attribute MAY be set to Response. 7. Alternate Approach: Use of L2TPv3 AVP for VPLS signaling Senevirathne Informational 9 draft-tsenevir-sig-nsp-00.txt August 2003 In this section we present extensions to L2TPv3 for VPLS signaling. Readers may compare extensions presented in this section with approach in section 6, where related attributes are packed in a single NSP Layer attribute message. We propose to define two new Message Types, VPLS-OP(TBA-17). AVP Remote End ID (AVP-TBA-8) is used to carry the VPN address. Based on the format of the VPN address, Length field will specify the size of the VPN address in octets. AVP Application Code (AVP-TBA-9) is used to identify the NSP type. For VPLS value (TBA-1) is proposed. Following new L2TPv3 attributes are defined. The syntax of the attributes are as specified in section 6. VPLS-Operation (AVP-TBA-?) VPLS-VLAN-Identifier (AVP-TBA-?) VPLS-Status (AVP-TBA-?) VPLS-Sequence (AVP-TBA-?) VPLS-Request-Response (AVP-TBA-?) Semantics of the above attributes, where applicable, are similar to the definitions in section 5 above. Message Sequence VPLS Local PE Remote PE VPLS | | (1) Create -----> | ------> ICRQ | | | | ICRP <----- | | | | ------> ICCN | | | | | (2) VPLS-OP-(a)-> | ---(a)->VPLS-OP | ---(a)--> VPLS-OP | | (2.1)VPLS-OP<---- | VPLS-OP<----- | <------ VPLS-OP | | | | | | (3) VPLS-OP-(b)--> | ---(b)-->VPLS-OP | --(b)---> VPLS-OP | | (3.1)VPLS-OP <-----| VPLS-OP <---- | <------ VPLS-OP | | | | | | Disconnect-----> -----> CDN | ------> Disconnect Senevirathne Informational 10 draft-tsenevir-sig-nsp-00.txt August 2003 (1) Create the session (2) Signal to create the VPLS (NSP) and (2.1) Bind VPLS instance to the session created at (1). (3) Signal to delete the VPLS (NSP), (3.1) Unbind the VPLS from session. (4) Delete the session (a) Message has VPLS-Operation attribute set to ADD. Hence effectively translating the semantics of the message to VPLS-ADD (b) Message has VPLS-Operation attribute set to DELETE. Hence effectively translating the semantics of the message to VPLS-DELETE Following AVP MUST be present in a NSP Message that generate a Request Message Type (VPLS) Local Session ID Remote Session ID Remote End ID Application Code VPLS-Operation VPLS-Sequence Following attribute MAY be present in a message that generate a Request VPLS-VLAN-Identifier VPLS-Request-Respnse Following AVP MUST be present in the NSP message that is generated as a response to a request message. Message Type (VPLS) Local Session ID Remote Session ID Remote End ID Application Code VPLS-Status VPLS-Sequence VPLS-Operation (set to RESPONSE) 8. Security Considerations L2TPv3 related security issues are presented in [4]. Publications that describe use of NSP Layer attribute defined here MUST specify related security issues. Senevirathne Informational 11 draft-tsenevir-sig-nsp-00.txt August 2003 9. Reference 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 Bryant, Stewart et.al, PWE3 Architecture, Work In Progress, August 2003. 4 Lau, J, et.al, Layer Two Tunneling Prrotocol (version 3), Work In Progress, July 2003 5 Agrawal, R. et.al, Transport of Ethernet Frames over L2TPv3, Work In Progress, 10. Acknowledgments Many Thanks to Mark Townsley for his valuable suggestions and comments. 11. Author's Addresses Tissa Senevirathne 1567 Belleville way, Sunnyvale, CA 94087 Phone: 408-245-5897 Email: tsenevir@hotmail.com Senevirathne Informational 12 draft-tsenevir-sig-nsp-00.txt August 2003 Full Copyright Statement "Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Senevirathne Informational 13