draft-ietf-forces-model-15.txt   draft-ietf-forces-model-16.txt 
Working Group: ForCES J. Halpern Working Group: ForCES J. Halpern
Internet-Draft Self Internet-Draft Self
Intended status: Standards Track J. Hadi Salim Intended status: Standards Track J. Hadi Salim
Expires: March 15, 2009 Znyx Networks Expires: April 10, 2009 Znyx Networks
September 11, 2008 October 7, 2008
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-15.txt draft-ietf-forces-model-16.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 15, 2009. This Internet-Draft will expire on April 10, 2009.
Comments are solicited and should be addressed to the working group's Comments are solicited and should be addressed to the working group's
mailing list at forces@peach.ease.lsoft.com and/or the author(s). mailing list at forces@peach.ease.lsoft.com and/or the author(s).
Abstract Abstract
This document defines the forwarding element (FE) model used in the This document defines the forwarding element (FE) model used in the
Forwarding and Control Element Separation (ForCES) protocol [2]. The Forwarding and Control Element Separation (ForCES) protocol [2]. The
model represents the capabilities, state and configuration of model represents the capabilities, state and configuration of
forwarding elements within the context of the ForCES protocol, so forwarding elements within the context of the ForCES protocol, so
that control elements (CEs) can control the FEs accordingly. More that control elements (CEs) can control the FEs accordingly. More
specifically, the model describes the logical functions that are specifically, the model describes the logical functions that are
present in an FE, what capabilities these functions support, and how present in an FE, what capabilities these functions support, and how
these functions are or can be interconnected. This FE model is these functions are or can be interconnected. This FE model is
intended to satisfy the model requirements specified in the ForCES intended to satisfy the model requirements specified in the ForCES
requirements document, RFC3654 [4]. requirements document, RFC3654 [6].
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Requirements on the FE model . . . . . . . . . . . . . . 7 2.1. Requirements on the FE model . . . . . . . . . . . . . . 7
2.2. The FE Model in Relation to FE Implementations . . . . . 8 2.2. The FE Model in Relation to FE Implementations . . . . . 8
2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8 2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8
2.4. Modeling Language for the FE Model . . . . . . . . . . . 9 2.4. Modeling Language for the FE Model . . . . . . . . . . . 9
2.5. Document Structure . . . . . . . . . . . . . . . . . . . 9 2.5. Document Structure . . . . . . . . . . . . . . . . . . . 10
3. ForCES Model Concepts . . . . . . . . . . . . . . . . . . . . 10 3. ForCES Model Concepts . . . . . . . . . . . . . . . . . . . . 10
3.1. ForCES Capability Model and State Model . . . . . . . . . 11 3.1. ForCES Capability Model and State Model . . . . . . . . . 11
3.1.1. FE Capability Model and State Model . . . . . . . . . 12 3.1.1. FE Capability Model and State Model . . . . . . . . . 12
3.1.2. Relating LFB and FE Capability and State Model . . . 13 3.1.2. Relating LFB and FE Capability and State Model . . . 13
3.2. Logical Functional Block (LFB) Modeling . . . . . . . . . 14 3.2. Logical Functional Block (LFB) Modeling . . . . . . . . . 14
3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 17 3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 17
3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 20 3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 20
3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 23 3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 23
3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 24 3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 26 3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 26
skipping to change at page 4, line 6 skipping to change at page 4, line 6
8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 126 8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 126
8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 127 8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 127
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128
9.1. URN Namespace Registration . . . . . . . . . . . . . . . 128 9.1. URN Namespace Registration . . . . . . . . . . . . . . . 128
9.2. LFB Class Names and LFB Class Identifiers . . . . . . . . 128 9.2. LFB Class Names and LFB Class Identifiers . . . . . . . . 128
10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 129 10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 129
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 130 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 130
12. Security Considerations . . . . . . . . . . . . . . . . . . . 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 130
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.1. Normative References . . . . . . . . . . . . . . . . . . 130 13.1. Normative References . . . . . . . . . . . . . . . . . . 130
13.2. Informative References . . . . . . . . . . . . . . . . . 130 13.2. Informative References . . . . . . . . . . . . . . . . . 131
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131
Intellectual Property and Copyright Statements . . . . . . . . . 132 Intellectual Property and Copyright Statements . . . . . . . . . 132
1. Definitions 1. Definitions
The use of compliance terminology (MUST, SHOULD, MAY) is used in The use of compliance terminology (MUST, SHOULD, MAY, MUST NOT) is
accordance with RFC2119 [1]. Such terminology is used in describing used in accordance with RFC2119 [1]. Such terminology is used in
the required behavior of ForCES forwarding elements or control describing the required behavior of ForCES forwarding elements or
elements in supporting or manipulating information described in this control elements in supporting or manipulating information described
model. in this model.
Terminology associated with the ForCES requirements is defined in Terminology associated with the ForCES requirements is defined in
RFC3654 [4] and is not copied here. The following list of RFC3654 [6] and is not copied here. The following list of
terminology relevant to the FE model is defined in this section. terminology relevant to the FE model is defined in this section.
FE Model -- The FE model is designed to model the logical processing FE Model -- The FE model is designed to model the logical processing
functions of an FE. The FE model proposed in this document includes functions of an FE. The FE model proposed in this document includes
three components: the modeling of individual logical functional three components: the modeling of individual logical functional
blocks (LFB model), the logical interconnection between LFBs (LFB blocks (LFB model), the logical interconnection between LFBs (LFB
topology) and the FE level attributes, including FE capabilities. topology) and the FE level attributes, including FE capabilities.
The FE model provides the basis to define the information elements The FE model provides the basis to define the information elements
exchanged between the CE and the FE in the ForCES Protocol [2]. exchanged between the CE and the FE in the ForCES Protocol [2].
skipping to change at page 7, line 15 skipping to change at page 7, line 15
Inter-FE Topology -- See FE Topology. Inter-FE Topology -- See FE Topology.
Intra-FE Topology -- See LFB Topology. Intra-FE Topology -- See LFB Topology.
LFB class library -- A set of LFB classes that has been identified as LFB class library -- A set of LFB classes that has been identified as
the most common functions found in most FEs and hence should be the most common functions found in most FEs and hence should be
defined first by the ForCES Working Group. defined first by the ForCES Working Group.
2. Introduction 2. Introduction
RFC3746 [5] specifies a framework by which control elements (CEs) can RFC3746 [7] specifies a framework by which control elements (CEs) can
configure and manage one or more separate forwarding elements (FEs) configure and manage one or more separate forwarding elements (FEs)
within a networking element (NE) using the ForCES protocol. The within a networking element (NE) using the ForCES protocol. The
ForCES architecture allows Forwarding Elements of varying ForCES architecture allows Forwarding Elements of varying
functionality to participate in a ForCES network element. The functionality to participate in a ForCES network element. The
implication of this varying functionality is that CEs can make only implication of this varying functionality is that CEs can make only
minimal assumptions about the functionality provided by FEs in an NE. minimal assumptions about the functionality provided by FEs in an NE.
Before CEs can configure and control the forwarding behavior of FEs, Before CEs can configure and control the forwarding behavior of FEs,
CEs need to query and discover the capabilities and states of their CEs need to query and discover the capabilities and states of their
FEs. RFC3654 [4] mandates that the capabilities, states and FEs. RFC3654 [6] mandates that the capabilities, states and
configuration information be expressed in the form of an FE model. configuration information be expressed in the form of an FE model.
RFC3444 [8] observed that information models (IMs) and data models RFC3444 [10] observed that information models (IMs) and data models
(DMs) are different because they serve different purposes. "The main (DMs) are different because they serve different purposes. "The main
purpose of an IM is to model managed objects at a conceptual level, purpose of an IM is to model managed objects at a conceptual level,
independent of any specific implementations or protocols used". independent of any specific implementations or protocols used".
"DMs, conversely, are defined at a lower level of abstraction and "DMs, conversely, are defined at a lower level of abstraction and
include many details. They are intended for implementors and include include many details. They are intended for implementors and include
protocol-specific constructs." Sometimes it is difficult to draw a protocol-specific constructs." Sometimes it is difficult to draw a
clear line between the two. The FE model described in this document clear line between the two. The FE model described in this document
is primarily an information model, but also includes some aspects of is primarily an information model, but also includes some aspects of
a data model, such as explicit definitions of the LFB class schema a data model, such as explicit definitions of the LFB class schema
and FE schema. It is expected that this FE model will be used as the and FE schema. It is expected that this FE model will be used as the
basis to define the payload for information exchange between the CE basis to define the payload for information exchange between the CE
and FE in the ForCES protocol. and FE in the ForCES protocol.
2.1. Requirements on the FE model 2.1. Requirements on the FE model
RFC3654 [4]defines requirements that must be satisfied by a ForCES FE RFC3654 [6]defines requirements that must be satisfied by a ForCES FE
model. To summarize, an FE model must define: model. To summarize, an FE model must define:
o Logically separable and distinct packet forwarding operations in o Logically separable and distinct packet forwarding operations in
an FE datapath (logical functional blocks or LFBs); an FE datapath (logical functional blocks or LFBs);
o The possible topological relationships (and hence the sequence of o The possible topological relationships (and hence the sequence of
packet forwarding operations) between the various LFBs; packet forwarding operations) between the various LFBs;
o The possible operational capabilities (e.g., capacity limits, o The possible operational capabilities (e.g., capacity limits,
constraints, optional features, granularity of configuration) of constraints, optional features, granularity of configuration) of
each type of LFB; each type of LFB;
skipping to change at page 9, line 39 skipping to change at page 9, line 39
Human readability was the most important factor considered when Human readability was the most important factor considered when
selecting the specification language, whereas encoding, decoding and selecting the specification language, whereas encoding, decoding and
transmission performance was not a selection factor. The encoding transmission performance was not a selection factor. The encoding
method for over the wire transport is not dependent on the method for over the wire transport is not dependent on the
specification language chosen and is outside the scope of this specification language chosen and is outside the scope of this
document and up to the ForCES protocol to define. document and up to the ForCES protocol to define.
XML is chosen as the specification language in this document, because XML is chosen as the specification language in this document, because
XML has the advantage of being both human and machine readable with XML has the advantage of being both human and machine readable with
widely available tools support. This document uses an XML Schema to widely available tools support. This document uses an XML Schema to
define the structure of the LFB Library documents, as defined in [9] define the structure of the LFB Library documents, as defined in [11]
and [10] and [11]. While these LFB Class definitions are not sent in and [4] and [5]. While these LFB Class definitions are not sent in
the ForCES protocol, these definitions comply with the the ForCES protocol, these definitions comply with the
recommendations in RFC3470 [9] on the use of XML in IETF protocols. recommendations in RFC3470 [11] on the use of XML in IETF protocols.
By useing XML Schema to define the structure for the LFB Library
documents, we have a very clear set of syntactic restrictions to go
with the desired semantic descriptions and restrictions covered in
this document. As a corrolary to that, if it is determined that a
change in the syntax is needed then a new schema will be required.
This would be identified by a different URN to identify the namespace
for such a new schema.
2.5. Document Structure 2.5. Document Structure
Section 3 provides a conceptual overview of the FE model, laying the Section 3 provides a conceptual overview of the FE model, laying the
foundation for the more detailed discussion and specifications in the foundation for the more detailed discussion and specifications in the
sections that follow. Section 4 and Section 5 constitute the core of sections that follow. Section 4 and Section 5 constitute the core of
the FE model, detailing the two major aspects of the FE model: a the FE model, detailing the two major aspects of the FE model: a
general LFB model and a definition of the FE Object LFB, with its general LFB model and a definition of the FE Object LFB, with its
components, including FE capabilities and LFB topology information. components, including FE capabilities and LFB topology information.
Section 6 directly addresses the model requirements imposed by the Section 6 directly addresses the model requirements imposed by the
ForCES requirements defined in RFC3654 [4] while Section 7 explains ForCES requirements defined in RFC3654 [6] while Section 7 explains
how the FE model should be used in the ForCES protocol. how the FE model should be used in the ForCES protocol.
3. ForCES Model Concepts 3. ForCES Model Concepts
Some of the important ForCES concepts used throughout this document Some of the important ForCES concepts used throughout this document
are introduced in this section. These include the capability and are introduced in this section. These include the capability and
state abstraction, the FE and LFB model construction, and the unique state abstraction, the FE and LFB model construction, and the unique
addressing of the different model structures. Details of these addressing of the different model structures. Details of these
aspects are described in Section 4 and Section 5. The intent of this aspects are described in Section 4 and Section 5. The intent of this
section is to discuss these concepts at the high level and lay the section is to discuss these concepts at the high level and lay the
skipping to change at page 13, line 7 skipping to change at page 13, line 11
While one could try to build an object model to fully represent the While one could try to build an object model to fully represent the
FE capabilities, other efforts found this approach to be a FE capabilities, other efforts found this approach to be a
significant undertaking. The main difficulty arises in describing significant undertaking. The main difficulty arises in describing
detailed limits, such as the maximum number of classifiers, queues, detailed limits, such as the maximum number of classifiers, queues,
buffer pools, and meters that the FE can provide. We believe that a buffer pools, and meters that the FE can provide. We believe that a
good balance between simplicity and flexibility can be achieved for good balance between simplicity and flexibility can be achieved for
the FE model by combining coarse level capability reporting with an the FE model by combining coarse level capability reporting with an
error reporting mechanism. That is, if the CE attempts to instruct error reporting mechanism. That is, if the CE attempts to instruct
the FE to set up some specific behavior it cannot support, the FE the FE to set up some specific behavior it cannot support, the FE
will return an error indicating the problem. Examples of similar will return an error indicating the problem. Examples of similar
approaches include DiffServ PIB RFC3317 [6] and Framework PIB RFC3318 approaches include DiffServ PIB RFC3317 [8] and Framework PIB RFC3318
[7]. [9].
3.1.1.2. FE State Model 3.1.1.2. FE State Model
The FE state model presents the snapshot view of the FE to the CE. The FE state model presents the snapshot view of the FE to the CE.
For example, using an FE state model, an FE might be described to its For example, using an FE state model, an FE might be described to its
corresponding CE as the following: corresponding CE as the following:
o on a given port, the packets are classified using a given o on a given port, the packets are classified using a given
classification filter; classification filter;
skipping to change at page 15, line 35 skipping to change at page 15, line 36
| (P,M) | |Components| |(P',M') | |Components| |(P",M") | | (P,M) | |Components| |(P',M') | |Components| |(P",M") |
| | +----------+ | | +----------+ | | | | +----------+ | | +----------+ | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | | |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Figure 2: Generic LFB Diagram Figure 2: Generic LFB Diagram
An LFB, as shown in Figure 2, may have inputs, outputs and components An LFB, as shown in Figure 2, may have inputs, outputs and components
that can be queried and manipulated by the CE via an Fp reference that can be queried and manipulated by the CE via an Fp reference
point (defined in RFC3746 [5]) and the ForCES protocol termination point (defined in RFC3746 [7]) and the ForCES protocol termination
point. The horizontal axis is in the forwarding plane for connecting point. The horizontal axis is in the forwarding plane for connecting
the inputs and outputs of LFBs within the same FE. P (with marks to the inputs and outputs of LFBs within the same FE. P (with marks to
indicate modification) indicates a data packet, while M (with marks indicate modification) indicates a data packet, while M (with marks
to indicate modification) indicates the metadata associated with a to indicate modification) indicates the metadata associated with a
packet. The vertical axis between the CE and the FE denotes the Fp packet. The vertical axis between the CE and the FE denotes the Fp
reference point where bidirectional communication between the CE and reference point where bidirectional communication between the CE and
FE occurs: the CE to FE communication is for configuration, control, FE occurs: the CE to FE communication is for configuration, control,
and packet injection, while FE to CE communication is used for packet and packet injection, while FE to CE communication is used for packet
redirection to the control plane, reporting of monitoring and redirection to the control plane, reporting of monitoring and
accounting information, reporting of errors, etc. Note that the accounting information, reporting of errors, etc. Note that the
skipping to change at page 41, line 5 skipping to change at page 41, line 5
4. Model and Schema for LFB Classes 4. Model and Schema for LFB Classes
The main goal of the FE model is to provide an abstract, generic, The main goal of the FE model is to provide an abstract, generic,
modular, implementation-independent representation of the FEs. This modular, implementation-independent representation of the FEs. This
is facilitated using the concept of LFBs, which are instantiated from is facilitated using the concept of LFBs, which are instantiated from
LFB classes. LFB classes and associated definitions will be provided LFB classes. LFB classes and associated definitions will be provided
in a collection of XML documents. The collection of these XML in a collection of XML documents. The collection of these XML
documents is called a LFB class library, and each document is called documents is called a LFB class library, and each document is called
an LFB class library document (or library document, for short). Each an LFB class library document (or library document, for short). Each
of the library documents MUST conform to the schema presented in this of the library documents MUST conform to the schema presented in this
section. The root element of the library document is the section. The schema here, and the rules for confoming to the schema
<LFBLibrary> element. are those defined by the W3C in the definitions of XML schema in XML
Schema [4] and XML Schema DataTypes [5]. The root element of the
library document is the <LFBLibrary> element.
It is not expected that library documents will be exchanged between It is not expected that library documents will be exchanged between
FEs and CEs "over-the-wire". But the model will serve as an FEs and CEs "over-the-wire". But the model will serve as an
important reference for the design and development of the CEs important reference for the design and development of the CEs
(software) and FEs (mostly the software part). It will also serve as (software) and FEs (mostly the software part). It will also serve as
a design input when specifying the ForCES protocol elements for CE-FE a design input when specifying the ForCES protocol elements for CE-FE
communication. communication.
The following sections describe the portions of an LFBLibrary XML The following sections describe the portions of an LFBLibrary XML
Document. The descriptions primarily provide the necessary semantic Document. The descriptions primarily provide the necessary semantic
skipping to change at page 110, line 15 skipping to change at page 110, line 15
5.3.4.3. NeighborInterface 5.3.4.3. NeighborInterface
This identifies the interface on the neighbor through which the This identifies the interface on the neighbor through which the
neighbor is reached. The interface identification is needed when neighbor is reached. The interface identification is needed when
either only one side of the adjacency has configuration information, either only one side of the adjacency has configuration information,
or the two FEs are adjacent on more than one interface. or the two FEs are adjacent on more than one interface.
6. Satisfying the Requirements on FE Model 6. Satisfying the Requirements on FE Model
This section describes how the proposed FE model meets the This section describes how the proposed FE model meets the
requirements outlined in Section 5 of RFC3654 [4]. The requirements requirements outlined in Section 5 of RFC3654 [6]. The requirements
can be separated into general requirements (Section 5, 5.1 - 5.4) and can be separated into general requirements (Section 5, 5.1 - 5.4) and
the specification of the minimal set of logical functions that the FE the specification of the minimal set of logical functions that the FE
model must support (Section 5.5). model must support (Section 5.5).
The general requirement on the FE model is that it be able to express The general requirement on the FE model is that it be able to express
the logical packet processing capability of the FE, through both a the logical packet processing capability of the FE, through both a
capability and a state model. In addition, the FE model is expected capability and a state model. In addition, the FE model is expected
to allow flexible implementations and be extensible to allow defining to allow flexible implementations and be extensible to allow defining
new logical functions. new logical functions.
skipping to change at page 130, line 44 skipping to change at page 130, line 44
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Doria, A., Haas, R., Hadi Salim, J., Khosravi, H., and W. Wang, [2] Doria, A., Haas, R., Hadi Salim, J., Khosravi, H., and W. Wang,
"ForCES Protocol Specification", work in progress, draft-ietf - "ForCES Protocol Specification", work in progress, draft-ietf -
forces-protocol-11.txt, December 2007. forces-protocol-11.txt, December 2007.
[3] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [3] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[4] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1,
http://www.w3.org/TR/ xmlschema-1/, May 2001.
[5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
W3C REC-xmlschema-2, http://www.w3.org/TR /xmlschema-2/,
May 2001.
13.2. Informative References 13.2. Informative References
[4] Khosravi, H. and T. Anderson, "Requirements for Separation of [6] Khosravi, H. and T. Anderson, "Requirements for Separation of
IP Control and Forwarding", RFC 3654, November 2003. IP Control and Forwarding", RFC 3654, November 2003.
[5] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding [7] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding
and Control Element Separation (ForCES) Framework", RFC 3746, and Control Element Separation (ForCES) Framework", RFC 3746,
April 2004. April 2004.
[6] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, [8] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie,
"Differentiated Services Quality of Service Policy Information "Differentiated Services Quality of Service Policy Information
Base", RFC 3317, March 2003. Base", RFC 3317, March 2003.
[7] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework [9] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework
Policy Information Base", RFC 3318, March 2003. Policy Information Base", RFC 3318, March 2003.
[8] Pras, A. and J. Schoenwaelder, "On the Difference between [10] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January 2003. Information Models and Data Models", RFC 3444, January 2003.
[9] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the [11] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the
Use of Extensible Markup Language (XML) within IETF Protocols", Use of Extensible Markup Language (XML) within IETF Protocols",
BCP 70, RFC 3470, January 2003. BCP 70, RFC 3470, January 2003.
[10] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1,
http://www.w3.org/TR/ xmlschema-1/, May 2001.
[11] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
W3C REC-xmlschema-2, http://www.w3.org/TR /xmlschema-2/,
May 2001.
[12] Davis, M. and M. Suignard, "UNICODE Security Considerations", [12] Davis, M. and M. Suignard, "UNICODE Security Considerations",
http://www.unicode.org/ reports/tr36/tr36-3.html, July 2005. http://www.unicode.org/ reports/tr36/tr36-3.html, July 2005.
Authors' Addresses Authors' Addresses
Joel Halpern Joel Halpern
Self Self
P.O. Box 6049 P.O. Box 6049
Leesburg,, VA 20178 Leesburg,, VA 20178
 End of changes. 28 change blocks. 
42 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/