Internet Draft R, Nait Takourout
Expiration: November 2003 Ericsson Research Canada
File:draft-nait-forces-xml-model-00.txt June 2003
Working Group: ForCES
XML based Model for Control and Forward Element Separation
draft-nait-forces-xml-model-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 set of modeling requirements for the
logical elements between the control and data forwarding planes
of a network element. This document presents a model representation
of ForCES logical elements with the W3C Extensible Markup Language
[3].
Table of Contents
Nait Takourout Expires November 2003 [Page 1]
Internet Draft ForCES XML based model June 2003
1. Abstract........................................................1
2. Definitions.. ..................................................2
3. Introduction ...................................................4
4. XML based Modeling..............................................4
4.1. CE Specification................................................5
4.2. FE Model........................................................6
5. References......................................................8
5.1. Normative References............................................8
5.2. Informative References..........................................8
6. Security Considerations.........................................8
7. Authors' Addresses & Acknowledgments............................8
Appendix-1.........................................................9
Appendix-2........................................................11
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.
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.
Nait Takourout Expires November 2003 [Page 2]
Internet Draft ForCES XML based model June 2003
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.
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
Nait Takourout Expires November 2003 [Page 3]
Internet Draft ForCES XML based model June 2003
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
3. Introduction
The ForCES architecture [2] introduces a large set of components
like CE an FE in order to develop a flexible framework for future
high performance network element. So, the architecture has to
provide a scalable base that enables to manage the diversity of
functionalities inside FE and CE.
Those requirements introduce the modeling problematic. Inside
this document, we provide a XML [3] based model for FE (FE Model)
and for CE specifications. In fact, a CE implements a part of
protocol stacks, so it has to declare to its manager its data
processing limitations and its need in logical functions terms
(Ethernet Ports, DiffServ conditioning functions) to process packets.
4. XML based Modeling
The choice to use XML to represent the modeling of PEs is based on
the fact that the diversity between the physical implementations
of FEs and the needs of CEs requires a global interaction solution.
The design goals for XML, taken from [3], are:
o XML shall be straightforwardly usable over the Internet.
o XML shall support a wide variety of applications.
o XML shall be compatible with SGML.
o It shall be easy to write programs which process XML documents.
o The number of optional features in XML is to be kept to the
absolute minimum, ideally zero.
o XML documents should be human-legible and reasonably clear.
o The XML design should be prepared quickly.
o The design of XML shall be formal and concise.
o XML documents shall be easy to create.
o Terseness in XML markup is of minimal importance.
XML is a flexible language for modeling CE and FE. The choice of
this language optimizes the interoperability of the architecture
and its scalability.
Nait Takourout Expires November 2003 [Page 4]
Internet Draft ForCES XML based model June 2003
4.1 CE Specification
A CE has to declare its needs and its restrictions (of processing
capacities for example) to see whether these services are available
among FEs pertaining to the network element. The types of service
required by CE could be based on ForCES requirements.
So, A CE has to provide two types of information to its CE Manager.
Firstly, The CE provides its capabilities.
This list provides a minimal list of capabilities:
o The maximum number of FE that could be supported.
o The types of encapsulation supported for the post-association
phase.
o Its support of Failover mechanisms.
Secondly, it indicates its needs in term of FE
functionalities.
This list provides a minimal list of functionalities:
o Port functions (ethernet, frame-relay, etc.)
o Forwarding functions (IPv4, IPv6, unicast, multicast, etc.)
o Quality of Services (IntServ, DiffServ)
o Encapsulation functions (NAT, IPv6-in-IPv4, etc.)
o Security functions (IPSec, etc.)
The XML Document Type Definition (DTD) is available in the Appendix-1.
From the CE Manager point of view, this CE Specification allows to
provide a pertinent list of FEs to begin the post-association phase and
to manage the CE redundancy functionalities in regrouping CE who
have the same specifications.
Below is a XML representation of a simple CE Specification
for a DiffServ enabled CE:
3XMLEnableEthernet
Nait Takourout Expires November 2003 [Page 5]
Internet Draft ForCES XML based model June 2003
DiffServ
4.2 FE Model
The ForCES requirements indicate that the FE Model MUST define both a capability model
and a state model, which expresses the current configuration of the
device.
Moreover, those requirements define a minimum set of Logical Function
available inside a FE:
1)Port Functions
2)Forwarding Functions
3)QoS Functions
4)Generic Filtering Functions
5)Vendor-Specific Functions
6)High-Touch Functions
7)Security Functions
8)Off-loaded Functions
9)IPFLOW/PSAMP Functions
Below is an example of a XML representation.
In this example, the FE Model is split into the Capability Model
represented by a list of Logical Bloc (LB) and the State Model
represented by a list of Links.
...
...
Each logical bloc presents it-self as below with a handle and a
description of its capabilities
Nait Takourout Expires November 2003 [Page 6]
Internet Draft ForCES XML based model June 2003
5ethernet-csmacd1500100
And each Link markup indicates how logical blocs are linked
the ones to the others:
12
The XML Document Type Definition of the FE Model is available in
the Appendix-2.
Currently, the list of Logical Bloc supported are:
o Interface
o IpPrefixForwarder
logical representation of a IP Prefix forwarder
o IpNHForwarder
logical representation of a IP Next Hop forwarder
o IptoL2
logical representation of the entity linking L3 addresses
and L2 addresses like ARP
o DS_Classifier
logical representation of a DiffServ Classifier
o DS_Meter
logical representation of a DiffServ Meter
o DS_Action
logical representation of a DiffServ Action (Counter, Dropper,
etc.)
o DS_Queue
logical representation of a DiffServ Queue
o DS_Scheduler
logical representation of a DiffServ Scheduler
This list of logical blocs is based on RFC 3289 [4] and the work of the
Network Processing Forum [5].
[[
Remarks:
Some points have to be clarified:
Nait Takourout Expires November 2003 [Page 7]
Internet Draft ForCES XML based model June 2003
o the statistic representation problematic.
o the possibility to use XML namespace.
o to complete the Function markup in the CE Specification
with new requirements of [1].
]]
5. References
5.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] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0 (Second Edition)", , October 2000, .
[4] Baker, F et. al., "Management Information Base for the
Differentiated Services Architecture", RFC3292, May 2002.
5.2.Informative References
[5] Network Processing Forum, .
6. Security Considerations
The data inside the models could be significant for the CE and FE
Managers that could want to guarantee the confidentiality of the
attributes of theirs PEs. So, an appropriate security protocol
like IPSec to ensure the encryption level needed is required.
Moreover, some Managers could need to ensure the authentication of
the model of theirs PEs.
7. 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 8]
Internet Draft ForCES XML based model June 2003
Appendix-1: XML DTD for CE Specification
Nait Takourout Expires November 2003 [Page 9]
Internet Draft ForCES XML based model June 2003
Nait Takourout Expires November 2003 [Page 10]
Internet Draft ForCES XML based model June 2003
Appendix-2: XML DTD for FE Model
Nait Takourout Expires November 2003 [Page 11]
Internet Draft ForCES XML based model June 2003
Nait Takourout Expires November 2003 [Page 12]
Internet Draft ForCES XML based model June 2003
Nait Takourout Expires November 2003 [Page 13]