ForCES Working Group W. M. Wang
Internet-Draft Zhejiang Gongshang Univ.
Expires: Augest, 2006 J. Hadi Salim
Znyx Networks
Feb. 2006
ForCES Transport Mapping Layer (TML) Service Primitives
draft-jhs-forces-tmlsp-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 [RFC2119].
Abstract
This document proposes Service Primitives of Transport Mapping Layer
(TML) in a Forwarding and Control Element Separation(ForCES) network
Internet Draft ForCES TML SP Feb. 2005
element, to standardize the operations of ForCES Protocol Layer (PL)
to various types of TMLs.
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 [RFC2119].
Table of Contents
1. Introduction....................................................2
2. Definitions.....................................................3
3. Overview........................................................3
3.1. ForCES Protocol Framework..................................3
3.2. TML Requirements...........................................4
4. TML Modeling....................................................5
4.1. TML events.................................................6
4.2. TML attributes.............................................9
4.3. TML capabilities..........................................13
5. Service Primitives.............................................13
5.1. Design Principles.........................................13
5.2. Objectives................................................13
5.3. TML Open..................................................14
5.4. TML close.................................................14
5.5. TML Configuration.........................................15
5.6. TML Query.................................................15
5.7. TML send..................................................16
5.8. TML receive...............................................17
6. Theory of Operation............................................17
7. References.....................................................17
8. Author's Address...............................................17
Appendix A. TML Attributes XML file...............................18
1. Introduction
The Forwarding and Control Element Separation (ForCES) is a proposed
architecture for network elements like routers, documents of which
include RFC3654, RFC3746, and the ForCES protocol[ForCES-PL] and the
ForCES FE model[ForCES-Model] that are working in progress. RFC3654
defines the ForCES requirements, RFC3746 defines the ForCES framework,
and the ForCES protocol defines the message exchanging protocol
between the Forwarding Element (FE) and the Control Element (CE) in
the ForCES NE.
The ForCES protocol infrastructure constitutes of two components:
Hadi Salim Expires Augest, 2006 [Page 2]
Internet Draft ForCES TML SP Feb. 2005
1. The Protocol Layer (PL), which is responsible for generating
ForCES protocol messages and also processing protocol messages that
come from peering protocol layers in the same ForCES NE.
2. The Transport Mapping Layer (TML), which is responsible for
ForCES protocol message transports over variant transport media like
IP, Ethernet, ATM, etc.
The ForCES protocol, which mainly define the PL, is being worked to
be standardized by IETF. TMLs according to various transport media
are also to be individually standardized by IETF. A ForCES PL
implementation must be portable across all TMLs. It makes feasible
that the implementers of TML and PL maybe from different
organizations. As a result, there must be a standard method to
interconnect PL and TML. A private method would make the PL and TML
implementations also private.
The purpose of this document is to present the method that
standardize the interconnection of PL and variant TMLs. Although
there might be other choices like using PL-TML messages, as a more
efficient way for data transmission and processing, a method based on
service primitives are recommended for interconnection of PL and TML.
In this document, a set of TML Service Primitives are presented and
related TML parameters are defined. Also presented in the document is
the theory of operation of PL-TML based on the service primitives and
the parameters.
2. Definitions
This document follows the terminology used by the ForCES
protocol[ForCES-PL]. Some are just copied here:
ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
architecture that defines the ForCES protocol messages, the protocol
state transfer scheme, as well as the ForCES protocol architecture
itself (including requirements of ForCES TML (see below).
Specifications of ForCES PL are defined by [ForCES-PL].
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
ForCES protocol architecture that uses the capabilities of existing
transport protocols to specifically address protocol message
transportation issues, such as how the protocol messages are mapped
to different transport media (like TCP, IP, ATM, Ethernet, etc), and
how to achieve and implement reliability, multicast, ordering, etc.
The ForCES TML specifications are detailed in separate ForCES
documents, one for each TML.
3. Overview
3.1. ForCES Protocol Framework
Hadi Salim Expires Augest, 2006 [Page 3]
Internet Draft ForCES TML SP Feb. 2005
The ForCES protocol has presented the protocol framework as in
Figure 1. The framework shows the relationship between PL and TML.
According to this framework, TML lies under PL and provides services
to the PL. CE PL communicates with FE PL via CE TML and FE TML. On
transmit, the PL delivers its ForCES messages to the TML. The TML
further delivers the message to the destination TML(s). On receive,
the TML delivers the ForCES messages it received to the PL.
+-----------------------------------------------
| CE PL layer |
+-----------------------------------------------
| CE TML layer |
+-----------------------------------------------
^
|
ForCES |
protocol |
messages |
|
|
|
v
+-----------------------------------------------
| FE TML layer |
+-----------------------------------------------
| FE PL layer |
+-----------------------------------------------
Figure 1
3.2. TML Requirements
The ForCES protocol [ForCES-PL] also presents TML requirements. We
list the requirements as below. These requirements are expected to be
delivered by TML using any kind of transport media, though the text
does not define how such mechanisms are delivered. Each TML must
describe how it contributes to achieving the requirements. If for any
reason a TML does not provide a service listed below a justification
needs to be provided.
The TML requirements are:
1. Reliability
As defined by RFC 3654, section 6 #6.
2. Security
Hadi Salim Expires Augest, 2006 [Page 4]
Internet Draft ForCES TML SP Feb. 2005
TML provides security services to the ForCES PL. TML layer should
support the following security services and describe how they are
achieved.
* Endpoint authentication of FE and CE.
* Message Authentication
* Confidentiality service
3. Congestion Control
The congestion control scheme used needs to be defined. The
congestion control mechanism defined by the TML should prevent the FE
from being overloaded by the CE or the CE from being overwhelmed by
traffic from the FE. Additionally, the circumstances under which
notification is sent to the PL to notify it of congestion must be
defined.
4.Uni/multi/broadcast addressing/delivery if any
If there is any mapping between PL and TML level Uni/Multi/Broadcast
addressing it needs to be defined.
5. HA decisions
It is expected that availability of transport links is the TML's
responsibility. However, on config basis, the PL layer may wish to
participate in link failover schemes and therefore the TML must
support this capability.
6. Encapsulations used.
Different types of TMLs will encapsulate the PL messages on
different types of headers. The TML needs to specify the
encapsulation used.
7. Prioritization
It is expected that the TML will be able to handle up to 8 priority
levels needed by the PL layer and will provide preferential treatment.
TML needs to define how this is achieved. The requirement for
supporting up to 8 priority levels does not mean that the underlying
TML MUST be capable of handling up to 8 priority levels. In such an
event the priority levels should be divided between the available TML
priority levels. For example, if the TML only supports 2 priority
levels, the 0-3 could go in one TML priority level, while 4-7 could
go in the other.
8. Protection against DoS attacks
As described in the Requirements RFC 3654, section 6
4. TML Modeling
Hadi Salim Expires Augest, 2006 [Page 5]
Internet Draft ForCES TML SP Feb. 2005
To make PL capable of interconnection with variant TMLs in a
standardized way, the first work to do is to model the variant TMLs
in a uniform way from the perspective of a uniform PL.
Identical to modeling an LFB in an FE, from the perspective of PL,
TML properties can be abstracted by the following entities:
TML Events:
The TML events that PL requires to know when the events happen in
the TML.
TML attributes:
The TML attributes that are required to be configured by PL
according to PL requirements. The attributes can also be queried by
PL.
TML capabilities:
The TML capabilities that PL are interested to know.
Note that, not all TML properties should be made perceivable by PL
from PL point of view. PL only cares those TML properties that are
common to all TMLs and that PL should interact with via service
primitives so that TML can work according to PL's requirements.
Via TML Service Primitives, PL should be able to access above
properties of variant TMLs.
4.1.TML events
There might be several TML events, but only some of them are PL must
sense via PL-TML interface.
A callback mechanism is defined for PL to sense the TML events by
PL-TML service primitives. PL first provides every event with a
callback function for the event processing in the PL. PL then tells
the callback handle to TML by service primitives. The callback handle
is usually stored in TML as a parameter. Whenever the relavent event
happens in TML, the TML triggers the handle to notify PL of the event.
PL executes the callback function, and asynchronously begins to
process the event.
After a TML event happened and PL is notified and a procedure to
process the event is executed, PL may be further interested in
knowing if the event status in the TML still exists or not. To meet
this requirement, an 'eventState' parameter is used in callback
functions to indicate if the reported is the event happened or the
event released. Whereas, not all events need to notify PL of their
release state.
Hadi Salim Expires Augest, 2006 [Page 6]
Internet Draft ForCES TML SP Feb. 2005
The following TML events must be made to be notified by PL. If for
any reason a TML does not provide the service, a justification needs
to be provided in the TML specification.
1) TML failure event
This event happens when there is a TML failure. It is up to
individual TML specifications and even individual implementations to
specify the detailed event triggering conditions, but usually, TML
failure should include the following cases:
. local TML link failure
. peer TML unavailable
. peer TML left
The different cases that cause the failure will be stated by a
failure code in the event callback function.
Callback handle for TML failure event is then defined as:
status = -- SUCCESS or errorIndication
callbackTMLFailureEvent(
IN eventState
IN failCode
)
Where,
eventState = EventHAPPENED or EventRELEASED
failCode indicates the failure case
2) Message arrival event
TML can make it as an event when a PL ForCES protocol message coming
from peering TML arrives at the TML and the TML has made it ready for
PL to receive the message. In this way, an asynchronous message
receive mode can be realized in PL. In addition to this asynchronous
mode, PL can also use a specific TML receive service primitive
(defined below) for synchronous reception of PL messages.
Callback handle for message arrival event is defined as:
status = -- SUCCESS or errorIndication
callbackTMLMsgArrivalEvent(
IN msglen
IN msgPDU
)
Where, msglen indicates the ForCES message length, and msgPDU is the
ForCES message body in its Protocol Data Unit format. There is no
need for message arrival event to notify a release state.
3) Control message congestion event
Hadi Salim Expires Augest, 2006 [Page 7]
Internet Draft ForCES TML SP Feb. 2005
ForCES control messages are defined as all ForCES protocol messages
except ForCES redirect messages. ForCES redirect messages are
identified by the ForCES message types being marked as
'PacketRedirect'.
This event happens when the TML comes to a congestion state for the
control message transmission. It is up to individual TML
specifications and even individual implementations to specify the
detailed event triggering conditions.
This event can be used by PL layer to monitor the control message
transmission. In FEs, this event may also be used to help monitoring
possible DoS attacks from redirected packets.
Callback handle for TML control message congestion event is defined
as:
status = -- SUCCESS or errorIndication
callbackTMLCtrMsgCongestEvent(
IN eventState
)
Where,
eventState = EventHAPPENED or EventRELEASED
4)Redirect message congestion event
This event happens when the TML comes to a congestion state for the
PL redirect message transmission. It is up to individual TML
specifications and even individual implementations to specify the
detailed event triggering conditions.
This event can be used by PL layer to monitor the redirect message
transmission. In FEs, this may also be used to help monitoring
possible DoS attacks from redirect packets.
Callback handle for TML redirect message congestion event is defined
as:
status = -- SUCCESS or errorIndication
callbackTMLRedMsgCongestEvent(
IN eventState
)
Where,
eventState = EventHAPPENED or EventRELEASED
5)DoS attack alert event
This event happens when the TML comes to a state that it feels there
are abnormal amount of PL redirect messages and there has made it
quite hard to transport PL control messages. Whereas, it is up to
Hadi Salim Expires Augest, 2006 [Page 8]
Internet Draft ForCES TML SP Feb. 2005
individual TML specifications and even individual implementations to
specify the detailed and precise triggering conditions for the event.
This event is used by PL to monitor the security state for TML
message transmission. In FEs, when this event happens, usually FE PL
should trigger a DoS attack alert event to inform CE of the event. CE
may take further effects trying to prevent the attack. Note that, the
event is an alert, when it happens, usually it does not mean the CE-
FE communication is totally lost.
Callback handle for TML DoS attack alert event is defined as:
status = -- SUCCESS or errorIndication
callbackTMLDoSAttackAlertEvent(
IN eventState
)
Where,
eventState = EventHAPPENED or EventRELEASED
4.2.TML attributes
1) Event handles
Event handles are handles for PL to access events. An event callback
function handle is used as the purpose. Defining the handles as an
attribute of the TML, then, for PL to set the handle to TML is for
the PL to subscribe to the TML for the event notification, to delete
the handle from the TML is to unsubscribe the event from the TML.
We define the event handle TML attribute as below:
Eventhandle
Event callback handle
eventType
event type represented by an ID
uint16
TMLFailureEvent
TML failure event
TMLMsgArrivalEvent
TML ForCES message arrival event
TMLCtrMsgCongestEvent
Hadi Salim Expires Augest, 2006 [Page 9]
Internet Draft ForCES TML SP Feb. 2005
TML ForCES congtrol message transmit congestion event
TMLRedMsgCongestEvent
TML ForCES redirect message transmit congestion event
TMLDoSAttackAlertEvent
TML DoS attack alert event
handle
callback function handle of the event
uint64
EventHandles
event handle table in the TML
EventHandle
2)multicast lists
This attribute is used for TML to multicast ForCES messages. The
multicast list should be configured by PL, but individual TML
specifications should define how such multicast list maps to TML
transport level multicast mechanisms.
A PL level multicast list includes a group ID for the multicast and
a number of members of the multicast. The members are represented by
PL level protocol src/destIDs (include FE ID and CE ID).
Note that, there might be more than one multicast group for
multicast applications. The multiple multicast lists form a multicast
list table in TML.
The attribute for the multicast lists is defined as below:
}
Hadi Salim Expires Augest, 2006 [Page 10]
Internet Draft ForCES TML SP Feb. 2005
McastList
a PL level multicast list for ForCES multicast transport
groupID
32bits group ID of the multicast
uint32
members
members of the multicast represented by FE ID or CE ID
uint32
McastLists
a table representing several multicast lists in the TML
McastList
3) Working TML Type
A TML implementation may be capable of several TML transport ways.
For example, a TML with IP transport media may be able to support
several transport protocols, like TCP+UDP, TCP+DCCP, SCTP, etc. In
this case, there should be a TML attribute describing the different
types and make PL able to switch among the types under the control of
CE.
The TML type is represented by an ID, defined as below:
TMLType
TML Type
uint16
Hadi Salim Expires Augest, 2006 [Page 11]
Internet Draft ForCES TML SP Feb. 2005
TmlTcpUdp
TML uses TCP+UDP
TmlTcpDccp
TML uses TCP+DCCP
TmlSctp
TML uses SCTP
TmlEth
TML uses Ethernet
TmlAtm
TML uses ATM
The TML attribute for the working TML type is defined as below:
WorkingTMLType
current working TML type assigned by PL
TMLType
Note that, the working TML type attribute may be configurable or may
only be readable depending on implementations. TML capability on the
TML type (defined below) will tell if it is configurable or not. To
query the TML type capability before configuring the working TML type
attribute will help to correctly configure it.
4) Media specific TML parameters
Individual TML may require configuring some TML parameters specific
to its TML media. There leave a space in TML service primitives for
such requirement. Individual TML specifications should provide
detailed definitions for such parameters.
5) Vendor specific TML parameters
Vendors of individual implementations of TML may require configuring
some TML parameters specific to its implementation. There leave a
space in TML service primitives for such requirement. Individual
Hadi Salim Expires Augest, 2006 [Page 12]
Internet Draft ForCES TML SP Feb. 2005
implementation should provide detailed definitions for such
parameters.
4.3. TML capabilities
1) Supported TML type
A TML implementation may be capable of several TML transport ways.
This capability indicates PL of the supported types.
The TML capability for the supported TML type is defined as below:
SupportedTMLType
supported TML types in the TML mechanism
TMLType
2) TML type configuration capability
TMLTypeConfigurable
TML Type configurable or not by PL
boolean
5. Service Primitives
5.1.Design Principles
Two principles are applied to this PL-TML service primitives design:
1.PL-TML service primitives should hide implementation details
regarding reliability, security, multicast, congestion control, etc
from PL.
2.PL-TML service primitives should avoid leading TML to read ForCES
protocol message PDU to get information, so as to immunize the TML
from the possible change of ForCES protocol PDU (like the protocol
update).
5.2.Objectives
There are several basic design objectives:
1. Support for unicast, multicast and broadcast PL level mechanisms.
2. support for both reliable and unreliable delivery.
3. Support for in-order or agnostic delivery.
Hadi Salim Expires Augest, 2006 [Page 13]
Internet Draft ForCES TML SP Feb. 2005
4. Support for timeliness requirements.
5. Support for both synchronous and asynchronous operations.
6. Support for event notifications from TML to PL.
5.3. TML Open
Syntax:
status = -- SUCCESS or errorIndication
TMLopen( )
Parameters:
none
Service Description:
The PL connects to the TML by invoking the TML open call. It highly
depends on the individual TML specifications what a TML should do
after receiving this call. For some TMLs, this primitive call may
only act as a signal to inform TML that PL is going to use the TML
for sending or receiving PL messages, while for some other TMLs, a
TML may have to do some TML level operation to prepare for PL usage
when receiving this primitive call. For example, For a connectionless
TML, this open primitive may does not have to do anything, while for
a connection-oriented TML, this open call may be a signal for the TML
to setup TML level connection(s) to peering TML(this actually means
the peer-to-peer TMLs do not have to always be connected after the
TML is initialized and during the post-association phase).
Another important point is, to better synchronize the operations
between peering PLs, the TML will have to discard all the PL messages
received from peering PL before the local TML has not yet been opened
by the local PL,
5.4. TML close
Syntax:
status = -- SUCCESS or errorIndication
TMLclose( )
Parameters:
none
Service Description:
In this call, the PL disconnects from the TML. It highly depends on
the individual TML specifications what a TML should do after
receiving this call. For some TMLs, this primitive call may only act
as a signal to inform TML that PL is not going to use the TML for
sending or receiving PL messages anymore, while for some other TMLs,
a TML may have to do some extra TML level operations to disconnect it
to peering TMLs. For example, for a connectionless TML, this
primitive may do not have to do anything, while for a connection-
Hadi Salim Expires Augest, 2006 [Page 14]
Internet Draft ForCES TML SP Feb. 2005
oriented TML, this primitive call may be a signal for the TML to
disconnect all TML level connections to peering TML.
Another important point is, to better synchronize the operations
between peering PLs, a TML will have to discard all PL messages
received by the TML after the TML has been closed by local PL.
5.5.TML Configuration
Syntax:
status = -- SUCCESS or errorIndication
TMLconfig(
IN operation
IN path
IN data
)
Parameters:
operation ?the operation type for the configuration. Two operations
are defined:
operation = ADD ?to add parameter
= DELETE ?to delete parameter
path ?a path composed of element ID(s) and (or) array index
pointing to the element to be configured.
(TBD)
data ?the data to be configured to the element.
(TBD)
Service Description:
This primitive is used by the PL to control the behavior of the TML
by the PL layer configuring the related property elements in the TML.
The element is indicated by the 'path'. The value to be configured to
the element is accessed by the 'data'.
5.6. TML Query
Syntax:
status = -- SUCCESS or errorIndication
TMLquery(
IN path
OUT data
)
Parameters:
path ?a path composed of element ID(s) and (or) array index
pointing to the element to be queried.
(TBD)
Hadi Salim Expires Augest, 2006 [Page 15]
Internet Draft ForCES TML SP Feb. 2005
data ?the data returned by the query.
(TBD)
Service Description:
This primitive is used by the PL to query the behavior of the TML.
The querying element is indicated by the 'path'. The value queried is
stored at the 'data' field. The TML executes the primitive by filling
out the data field with the queried value of the element.
5.7. TML send
Syntax:
status = -- SUCCESS or errorIndication
TMLsend(
IN msgDestID,
IN msgType,
IN msgPrio,
IN msgLength,
IN msgPDU,
)
Parameters:
msgDestID: the destination ID for the PL message to be sent
msgType: the message type for the PL message to be sent
msgPrio: the message priority for the PL message to be sent
msgLen: the message length to be sent
msgPDU: the ForCES protocol message to be sent in its PDU
Service Description:
In this service, the PL sends a message to one (unicast) or more
(multicast) peer PLs via the TML. Note that this primitive includes
all parameters that are necessary for TML to manage transmission of
the PL message, therefore, there is no need for the TML to read in
the PL message body to retrieve this parameters. In this way, we may
decouple changes in ForCES protocol PDU (e.g., by the protocol update)
from TML level.
The msgDestID is used for the TML to find out TML layer transport
addresses for the message transmission. It also includes the
processing for PL message multicast transports, for the destination
ID may also be a multicast group ID.
The msgType is used for the TML to infer the requirements from PL
level for the manage sending, regarding its reliability, timeliness,
security, and congestion control. With this message type, it is easy
to recognize PL redirect messages from PL control messages.
Hadi Salim Expires Augest, 2006 [Page 16]
Internet Draft ForCES TML SP Feb. 2005
Individual TML specifications should define how the msgTypes are used
to map into the TML requirements.
The msgPrio is used for the TML to meet the PL requirement for the
message transmission priority; it may also be used for TML to meet
the TML requirements for reliability, timeliness, security, and
congestion control. Individual TML specifications should define how
the priority is mapped into the TML transport mechanisms for
prioritized transmission. Individual TML specifications may also
define how the priority is used for other TML requirements.
5.8. TML receive
Syntax:
status = -- SUCCESS or errorIndication
TMLreceive(
IN msgLength,
IN msgPDU,
)
Parameters:
msgLen: the length of the message received.
msgPDU: the received ForCES protocol message body in its PDU
format
Service Description:
This service is used for PL to synchronously receive PL messages
from peering TML.
Note that a PL message arrival event described before can also be
used for PL to receive PL messages from TML. The difference is that
this TML receive primitive makes PL to synchronously receive messages,
while a PL message arrival event receives messages in an asynchronous
way. Usually, an asynchronous method is more efficient in terms of
CPU cycles.
6. Theory of Operation
(TBD)
7. References
[ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft-
ietf-forces-protocol-06.txt, work-in-progress, Dec. 2005.
[ForCES-Model] Yang, L., "ForCES Forwarding Element Model", Aug.
2003, http://www.ietf.org/internet-drafts/draft-ietf-forces-model-
05.txt.
8. Author's Address
Hadi Salim Expires Augest, 2006 [Page 17]
Internet Draft ForCES TML SP Feb. 2005
Weiming Wang
Zhejiang Gongshang University
149 Jiaogong Road
Hangzhou 310035
P.R.China
Phone: +86-571-88071024
EMail: wmwang@mail.zjgsu.edu.cn
Jamal Hadi Salim
Znyx Networks
195 Stafford Rd. West
Ottawa, Ontario
Canada
Email: hadi@znyx.com
Appendix A. TML Attributes XML file
(TBD)
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
Hadi Salim Expires Augest, 2006 [Page 18]
Internet Draft ForCES TML SP Feb. 2005
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hadi Salim Expires Augest, 2006 [Page 19]