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,<draft-ietf-forces-
requirements-09.txt>.
[2] Yang, L. et al., "Forwarding and Control Element Separation
(ForCES) Framework ", work in progress, June 2003, <draft-ietf-
forces-framework-06.txt>.
[3] Khosravi, H. et al., " ForwArding and Control ElemenT protocol
(FACT)", work in progress, March 2003, <draft-gopal-forces-fact-
03.txt>.
7.2.Informative References
[4] Maloy, J., "Telecom Inter Process Communication", work in
progress, Jan 2002, <http://tipc.sourceforge.net>
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]