Internet Draft R, Nait Takourout Expiration: November 2003 Ericsson Research Canada File: draft-nait-forces-pap-00.txt June 2003 Working Group: ForCES Pre Association Phase Protocol (PAP) draft-nait-forces-pap-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 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]. 1. Abstract This document introduces a protocol for the pre-association phase as defined in the ForCES (Forwarding and Control Element Separation) requirements documents [1]. The main purpose of this protocol is to bring mechanisms to automate the discovery and the configuration of logical elements in this ForCES architecture. Table of Contents Nait Takourout Expires November 2003 [Page 1] Internet Draft Pre-association Phase Protocol June 2003 1. Abstract........................................................1 2. Definitions.....................................................2 3. Introduction....................................................4 4. Protocol Overview...............................................5 5. Message overview................................................7 5.1. Message header structure......................................7 5.1.1. Version. ...................................................7 5.1.2. MsgType.....................................................7 5.1.3. Length......................................................8 5.1.4. Identifier..................................................8 5.1.5. F bit.......................................................8 5.1.6. Fragment OffSet.............................................8 5.2. Message payload structure.....................................8 5.2.1. EncapType...................................................9 5.2.2. Param Length................................................9 6. Message Types...................................................9 6.1. INIT_CE message...............................................9 6.2. INIT_FE message..............................................10 6.3. INIT_MANAGER message.........................................10 6.4. INIT_ACC message.............................................10 6.5. INIT_REJ message.............................................10 6.6. MODEL message................................................11 6.7. MODEL_ACK message............................................11 6.8. LIST message.................................................11 6.9. LIST_ACK message.............................................12 6.10. EVENT_INACTIVE message......................................12 6.11. EVENT_INACTIVE_ACK message..................................12 6.12. EVENT_LEAVE message.........................................12 6.13. EVENT_LEAVE_ACK message.....................................13 7. References.....................................................13 7.1. Normative References.........................................13 7.2. Informative References.......................................13 8. Security Considerations........................................13 9. Authors' Addresses & Acknowledgments...........................13 2. Definitions The following definitions are taken from [1]: Addressable Entity (AE) - A physical device that is directly addressable given some interconnect technology. For example, on IP networks, it is a device to which we can communicate using an IP address; and on a switch fabric, it is a device to which we can communicate using a switch fabric port number. Physical Forwarding Element (PFE) - An AE that includes hardware used to provide per-packet processing and handling. This hardware may consist of (but is not limited to) network processors, ASIC's, line cards with multiple chips or stand alone box with general- purpose processors. Nait Takourout Expires November 2003 [Page 2] Internet Draft Pre-association Phase Protocol June 2003 Physical Control Element (PCE) - An AE that includes hardware used to provide control functionality. This hardware typically includes a general-purpose processor. Forwarding Element (FE) - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per- packet processing and handling as directed/controlled by a CE via the ForCES protocol. FEs may happen to be a single blade(or PFE), a partition of a PFE or multiple PFEs. Control Element (CE) - A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs how to process packets. CEs handle functionality such as the execution of control and signaling protocols. CEs may consist of PCE partitions or whole PCEs. Pre-association Phase - The period of time during which a FE Manager (see below) and a CE Manager (see below) are determining which FE and CE should be part of the same network element. Any partitioning of PFEs and PCEs occurs during this phase. Post-association Phase - The period of time during which a FE does know which CE is to control it and vice versa, including the time during which the CE and FE are establishing communication with one another. ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES protocol" refers only to the ForCES post-association phase protocol (see below). ForCES Post-Association Phase Protocol - The protocol used for post- association phase communication between CEs and FEs. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. The ForCES protocol is a master-slave protocol in which FEs are slaves and CEs are masters. This protocol includes both the management of the communication channel (e.g., connection establishment, heartbeats) and the control messages themselves. This protocol could be a single protocol or could consist of multiple protocols working together. FE Model - A model that describes the logical processing functions of a FE. FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) a FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. A FE manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which CE(s) to use, however this is currently out of scope. Being a logical entity, a FE manager might be physically combined with any of the other logical entities mentioned in this section. Nait Takourout Expires November 2003 [Page 3] Internet Draft Pre-association Phase Protocol June 2003 CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. A CE manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which FE to use, however this is currently out of scope. Being a logical entity, a CE manager might be physically combined with any of the other logical entities mentioned in this section. Pre-association Phase Protocol - A protocol between FE managers and CE managers that is used to determine which CEs or FEs to use. A pre-association phase protocol may include a CE and/or FE capability discovery mechanism. Note that this capability discovery process is wholly separate from (and does not replace) that used within the ForCES protocol. However, the two capability discovery mechanisms may utilize the same FE model. ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. To entities outside a NE, the NE represents a single point of management. Similarly, a NE usually hides its internal organization from external entities. ForCES Protocol Element - A FE or CE. This document defines this terminology: CE Specification - A model that describes the capabilities and the needed logical processing functions of a CE. Telecom Inter Process Communication (TIPC) - The TIPC [4] protocol is specially designed for intra cluster communication. The main feature of TIPC is Full location transparency hiding all aspects of the cluster's physical topology for the application programs. 3. Introduction The ForCES architecture introduces the pre-association phase [2]. During this phase, any Protocol Element (PE) has to declare itself to its Manager in order to join a Network Element (NE). But, this mechanism has to be dynamic, interface technologies independent and scalable. This phase takes care of four operations: o Accept or reject a PE inside a Network Element. o Give an identifier to a PE if it is not defined. o Allow a Manager to discover the PE attributes. o Allow a CE (or a FE) to discover the FEs (or CE) and theirs attributes. Nait Takourout Expires November 2003 [Page 4] Internet Draft Pre-association Phase Protocol June 2003 The representation of CE or FE attributes could be done with XML documents, OIDs, etc.. 4. Protocol Overview The Pre-Association phase protocol is a communication protocol for the management of a network element. Its purpose is to provide an automatic discovery of the PEs. This protocol is designed to communicate between PEs and CE / FE Manager, and between Managers. The interaction between a PE and a Manager are subdivided into three phases. The first one represents the pre-association phase as defined in the ForCES framework [2]. The second is an event-based phase. In fact, if a PE doesn't succeed to join one PE of the list provided by the Manager during the pre-association phase. This one has to communicate with the Manager to obtain another list of PEs in an asynchronous way. And the last phase, it is just to indicate to the Manager that a PE wants to leave the NE. Those three phases are represented in the figure below: CE CE Manager FE FE Manager | | | | | Phase I | | Phase I | | | | | | INIT_CE | | INIT_FE | |------------------->| |------------------->| | INIT_ACC | | INIT_ACC | | or | | or | | INIT_REJ | | INIT_REJ | |<-------------------| |<-------------------| | | | | | MODEL | | MODEL | |------------------->| |------------------->| | | | | | MODEL_ACK | | MODEL_ACK | |<-------------------| |<-------------------| | | | | | Phase II | | Phase II | | | | | | EVENT_INACTIVE | | EVENT_INACTIVE | |------------------->| |------------------->| | | | | | EVENT_INACTIVE_ACK | | EVENT_INACTIVE_ACK | | or | | or | | MODEL_ACK | | MODEL_ACK | |<-------------------| |<-------------------| | | | | Nait Takourout Expires November 2003 [Page 5] Internet Draft Pre-association Phase Protocol June 2003 | | | | | Phase III | | Phase III | | | | | | EVENT_LEAVE | | EVENT_LEAVE | |------------------->| |------------------->| | | | | | EVENT_LEAVE_ACK | | EVENT_LEAVE_ACK | |<-------------------| |<-------------------| | | | | In a same way, the interaction between CE Manager and FE Manager are represented with three phases. The second phase is always for asynchronous interactions. For example if a CE indicates to the CE Manager that it wants to join the NE, the CE manager has to update the PE list of the FE Manager. The figure following illustrates it: CE Manager FE Manager | | | Phase I | | | | INIT_MANAGER | |<-------------------->| | INIT_ACC | | or | | INIT_REJ | |<-------------------->| | | | Phase II | | | | LIST | |<-------------------->| | | | LIST_ACK | |<-------------------->| | | | Phase III | | | | EVENT_LEAVE | |<-------------------->| | | | EVENT_LEAVE_ACK | |<-------------------->| | | The types of message defined in this example are: Message Type Description INIT_CE A CE wants to join the NE Nait Takourout Expires November 2003 [Page 6] Internet Draft Pre-association Phase Protocol June 2003 INIT_FE A FE wants to join the NE INIT_MANAGER A Manager wants to join a Manager INIT_ACC The request for joining the NE is accepted INIT_REJ The request for joining the NE is refused MODEL A PE sends its model. MODEL_ACK The Manager sends to a PE the list of other PEs, which can be reached for the post- association phase. LIST A CE (or FE) Manager sends to a FE (or a CE) Manager its list of PEs models and the list of theirs addresses. LIST_ACK The other Manager sends an acknowledgment EVENT_INACTIVE A PE is inactive and wants another list of PE to communicate EVENT_INACTIVE_ACK The inactive PE has to stay in an inactive state for a defined period [TBD] EVENT_LEAVE A PE or a Manager wants to leave the NE EVENT_INACTIVE_ACK An acknowledgment for an EVENT_LEAVE message In the next sections, we describe the messages of this protocol that are split into two parts: the header and the message payload part. 5. Message Overview 5.1. Message Header Structure Payload messages have the header format illustrated in the following figure. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | MsgType | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |F| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.1 Version This is a 5 bits field representing the version of this protocol. The current version is 0x01 5.1.2 MsgType This 11 bits field indicates the type of the messages. As we saw previously, the types could be: Message type Value INIT_CE 0x1 INIT_FE 0x2 INIT_MANAGER 0x3 INIT_ACC 0x4 Nait Takourout Expires November 2003 [Page 7] Internet Draft Pre-association Phase Protocol June 2003 INIT_REJ 0x5 MODEL 0x6 MODEL_ACK 0x7 LIST 0x8 LIST_ACK 0x9 EVENT_INACTIVE 0x10 EVENT_INACTIVE_ACK 0x11 EVENT_LEAVE 0x12 EVENT_LEAVE_ACK 0x13 5.1.3 Length This is the total length of the message in octets. 5.1.4 Identifier This is a 16 bits field to identify a message. Messages can be up to 64kb, so it is possible to split message into multiples fragments. If a message has to be fragmented, the different messages have to keep the same identification field to match up with other fragments. 5.1.5 F bit This bit indicates if the message is fragmented. Indeed, if this bit is set to 0, there is no other fragmented message following. Value Description 0 No Next fragments 1 There are more fragments 5.1.6 Fragment OffSet This 15 bits field indicates where this fragment lies in the global message. 5.2. Message Payload Structure The message payload structure is based on by a list of zero or more variable length parameters. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EncapType | Param Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ Value \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nait Takourout Expires November 2003 [Page 8] Internet Draft Pre-association Phase Protocol June 2003 5.2.1. EncapType This 16 bits field indicates the encapsulation type used in the payload. Value Description 0x1 BIN 0x2 XML 0x3 OID 5.2.2. Param Length This field indicates the length of this parameter in octets. 6. Message Types In this section, we define the value of the parameter of each message type. 6.1 INIT_CE message The format of the payload for INIT_CE message type, is as follows : 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddressType | Element Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ Address \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ModelingType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ Authentication Options \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AdressType: These 16 bits field indicates the type of address. Value Address type 0x1 No address 0x2 IPv4 0x3 IPv6 0x4 TIPC Element Id: Identifier of the CE. Address: Address of the CE. Nait Takourout Expires November 2003 [Page 9] Internet Draft Pre-association Phase Protocol June 2003 ModelingType: This 32 bits field indicates the type of representation for the CE Specification. Value Representation type 0x1 XML 0x2 OID 6.2 INIT_FE message The format for the message type payload is same as in INIT_CE Message. But the Element Id field contents the FE Identifier or 0 if it is not defined. 6.3 INIT_MANAGER message The format for the message type payload is same as in INIT_FE Message. But the Element Id field contents the Manager identifier. 6.4 INIT_ACC message The format of the payload for INIT_CE message type, is as follows : 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Element Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.5 INIT_REJ message The format of the payload for INIT_REJ message type, is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ INFO * \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reason: These 32 bits field indicates the reason of the reject. Value Reason 0x1 Authentication Fail 0x2 Management Inhibit (Manual Removal) 0x3 NE busy 0x4 Model representation not supported INFO: It is an optional field. Nait Takourout Expires November 2003 [Page 10] Internet Draft Pre-association Phase Protocol June 2003 6.6 MODEL message The payload for this type content just the CE Specification or the FE Model. 6.7 MODEL_ACK message The format of the payload for MODEL_ACK message type, is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddressType | Element Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ Address \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Others addresses of the list / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.8 LIST message The payload for this message type contains just the list of CE Specifications or FE Models and the list of addresses, which are represented by two parameters: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EncapType | Param Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ List of models \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BIN | Param Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddressType | Element Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ Address \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Others addresses of the list / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The values for the fields of this message type are the same as in MODEL and MODEL_ACK messages. Nait Takourout Expires November 2003 [Page 11] Internet Draft Pre-association Phase Protocol June 2003 6.9 LIST_ACK message This message type is just an acknowledgement and doesn't contain payload. 6.10 EVENT_INACTIVE message The format of the payload for EVENT_INACTIVE message type, is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ INFO * \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reason: These 32 bits field indicates the reason of the inactivity. Value Reason 0x1 No PE could be reached. 0x2 Manual Inhibit. 0x3 PE busy INFO: It is an optional field. 6.11 EVENT_INACTIVE_ACK message The EVENT_INACTIVE_ACK message doesn't contain payload, but indicates to the PE to remain on standby for a given period of time [TBD]. 6.12 EVENT_LEAVE message The EVENT_LEAVE message contains the following parameters: Reason Info String (optional) The format for the message type payload is same as in EVENT_INACTIVE message but the values for the Reason field are: Value Description 0x1 Management Inhibit (Manual Removal) 0x2 Invalid NE group 0x3 FE or CE not ready 0x4 Max number of FEs reached 0x5 Physical Layer fault 0x6 Fail-over switching Those values are the same than for the Leave Request in the FACT protocol [3]. Nait Takourout Expires November 2003 [Page 12] Internet Draft Pre-association Phase Protocol June 2003 6.13 EVENT_LEAVE_ACK message The EVENT_LEAVE_ACK message contains the following parameters: Reason Info String (optional) The format for the message type payload and the values of field are the same as in EVENT_LEAVE message 7. References 7.1. Normative References [1] Khosravi, H. et al., "Requirements for Separation of IP Control and Forwarding", work in progress, May 2003,. [2] Yang, L. et al., "Forwarding and Control Element Separation (ForCES) Framework ", work in progress, June 2003, . [3] Khosravi, H. et al., " ForwArding and Control ElemenT protocol (FACT)", work in progress, March 2003, . 7.2.Informative References [4] Maloy, J., "Telecom Inter Process Communication", work in progress, Jan 2002, 8. Security Considerations If the PEs and the Managers are in an untrusted domain, the pre- association protocol MUST be used over an appropriate security protocol like IPSec to ensure the encryption level needed. 9. Author's Addresse & Acknowledgments Rachid Nait Takourout (Editor) Ecole Polytechnique de Montreal 2500, chemin de Polytechnique Montreal, H3T 1J4, Quebec, Canada Phone: +1 514 340 4711 email: rachid.nait-takourout@polymtl.ca The author would like to thank Jon Maloy, Laurent Marchand and Samuel Pierre for theirs valuable contributions. Nait Takourout Expires November 2003 [Page 13]