draft-ietf-forces-tmlsp-00.txt   draft-ietf-forces-tmlsp-01.txt 
ForCES Working Group W. M. Wang ForCES Working Group W. M. Wang
Internet-Draft Zhejiang Gongshang Univ. Internet-Draft Zhejiang Gongshang Univ.
Expires: October, 2006 J. Hadi Salim Expires: August, 2007 J. Hadi Salim
Znyx Networks Znyx Networks
Alex Audu
Garland SoftWorx
February, 2007
ForCES Transport Mapping Layer (TML) Service Primitives ForCES Transport Mapping Layer (TML) Service Primitives
draft-ietf-forces-tmlsp-00.txt draft-ietf-forces-tmlsp-01.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 line 32 skipping to change at page 2, line ?
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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.
Copyright Notice
Copyright (C) The Internet Society (2006).
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Abstract Abstract
This document proposes Service Primitives of Transport Mapping Layer This document specifies Transport Mapping Layer (TML) Service
(TML) in a Forwarding and Control Element Separation (ForCES) network Primitives for Forwarding and Control Element Separation (ForCES).
element, to standardize the operations of ForCES Protocol Layer (PL) Based on the service primitives, TML services that are provided by
to a variety of TMLs. TML to ForCES Protocol Layer (PL) are standardized. To define the
primitives, TML properties represented as TML events, TML attributes,
and TML capabilities are also specified in the document.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction....................................................2
2. Definitions.....................................................3 2. Definitions.....................................................3
3. Overview........................................................3 3. Overview........................................................3
3.1. ForCES Protocol Framework..................................3 3.1. ForCES Protocol Framework..................................3
3.2. TML Requirements...........................................4 3.2. TML Requirements...........................................4
4. TML Modeling....................................................5 4. TML Representation..............................................5
4.1. TML events.................................................6 4.1. TML events.................................................6
4.2. TML attributes.............................................9 4.2. TML attributes............................................11
4.3. TML capabilities..........................................12 4.3. TML capabilities..........................................14
5. Service Primitives.............................................13 5. TML Service Primitives.........................................15
5.1. Design Principles.........................................13 5.1. Design Principles.........................................15
5.2. Objectives................................................13 5.2. TML Open..................................................15
5.3. TML Open..................................................13 5.3. TML close.................................................16
5.4. TML close.................................................14 5.4. TML Configuration.........................................17
5.5. TML Configuration.........................................15 5.5. TML Query.................................................18
5.6. TML Query.................................................15 5.6. TML send..................................................20
5.7. TML send..................................................16 5.7. TML receive...............................................21
5.8. TML receive...............................................17 6. Operation Notes................................................22
6. Theory of Operation............................................17 7. Security Considerations........................................23
7. References.....................................................17 8. Acknowledgements...............................................24
8. Author's Address...............................................17 9. References.....................................................24
Appendix A. TML Attributes XML file...............................18 10. Author's Address..............................................24
1. Introduction 1. Introduction
The Forwarding and Control Element Separation (ForCES) is a proposed ForCES aims to define a set of specifications for routers, firewalls,
architecture for network elements like routers, documents of which gateways, etc based on the architecture of separation of Forwarding
include RFC3654, RFC3746, and the ForCES protocol[ForCES-PL] and the Elements (FEs) and Control Elements (CEs). RFC3654 has presented the
ForCES FE model[ForCES-Model] that are work in progress. RFC3654 ForCES requirements, and RFC3746 has defined the ForCES framework.
defines the ForCES requirements, RFC3746 defines the ForCES framework, The ForCES FE model [ForCES-Model] is specifying the model to
and the ForCES protocol defines the message exchange protocol between represent an FE. The ForCES protocol [ForCES-PL] is specifying the
the Forwarding Element (FE) and the Control Element (CE) in the information exchanging protocol between CE and FE.
ForCES NE (see RFC3654 for the terminology definitions).
The ForCES protocol infrastructure consists of two components: The ForCES protocol infrastructure consists of two layers:
1. The Protocol Layer (PL), which is responsible for generating 1. The Protocol Layer (PL), which is responsible for generating
ForCES protocol messages and also processing protocol messages that ForCES protocol messages, and processing protocol messages that come
come from peering protocol layers in the same ForCES NE. from peering protocol layer in the same ForCES NE.
Hadi Salim Expires Oct., 2006 [Page 2]
2. The Transport Mapping Layer (TML), which is responsible for 2. The Transport Mapping Layer (TML), which is responsible for
ForCES protocol message transports over variant transport media like transportation of ForCES protocol messages over variant transport
IP, Ethernet, ATM, etc. media, like IP, Ethernet, ATM, etc.
The IETF ForCES protocol mainly defines the PL. TMLs according to The ForCES protocol [ForCES-PL] document defines the specifications
various transport media are also to be individually defined by IETF. for PL, while TMLs of different transport media types are to be
A ForCES PL implementation must be portable across all TMLs. It is defined by individual IETF documents. A ForCES PL implementation must
feasible that the implementers of TML and PL may be from different be portable across all TMLs. It is feasible that the implementers of
organizations. As a result, there must be an interoperable method to TML and PL may be from different organizations. As a result, services
interconnect the PL and TML. A private method would make the PL and TML provides to PL must be specified in a standardizing way.
TML implementations also private.
The purpose of this document is to present the method for an The purpose of this document is to specify the services that various
interoperable interconnection of the PL and a variety of TMLs. TMLs must provide for ForCES PL layer. The TML services are
Although there might be other choices like using PL-TML messages, as represented by a set of TML service primitives and associated TML
a more efficient way for data transmission and processing, a method properties (TML attributes, etc).
based on service primitives are recommended for interconnection of PL
and TML. In this document, a set of TML Service Primitives are Note that this document specifies TML services more at a semantic
presented and related TML parameters are defined. Also presented in level, i.e., it does not try to specify details on how the defined
the document is the theory of operation of PL-TML based on the TML services shall be implemented. Different Operating System
service primitives and the parameters. platforms that PL and TML may rely on to be developed may have
different programming methods, process techniques, data structures,
etc for realizing the set of TML services. As a result, TML interface
APIs constructed according to this document may vary in some way. In
this condition, one PL portable to various TMLs actually means the PL
must provide various interface drivers for different TMLs, while
keeping the PL kernel the same for the TML operations.
2. Definitions 2. Definitions
This document follows the terminology used by RFC3654, RFC3746, and This document follows the terminology used by RFC3654, RFC3746, the
the ForCES protocol[ForCES-PL]. Some are just copied here: ForCES protocol[ForCES-PL], and the ForCES FE model [ForCES-Model].
For convenience, some definitions are just copied here:
ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
architecture that defines the ForCES protocol messages, the protocol architecture that defines the ForCES protocol messages, the protocol
state transfer scheme, as well as the ForCES protocol architecture state transfer scheme, as well as the ForCES protocol architecture
itself (including requirements of ForCES TML (see below). itself (including requirements of ForCES TML (see below).
Specifications of ForCES PL are defined by [ForCES-PL]. Specifications of ForCES PL are defined by [ForCES-PL].
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
ForCES protocol architecture that uses the capabilities of existing ForCES protocol architecture that uses the capabilities of existing
transport protocols to specifically address protocol message transport protocols to specifically address protocol message
transportation issues, such as how the protocol messages are mapped transportation issues, such as how the protocol messages are mapped
to different transport media (like TCP, IP, ATM, Ethernet, etc), and to different transport media (like TCP, IP, ATM, Ethernet, etc), and
how to achieve and implement reliability, multicast, ordering, etc. how to achieve and implement reliability, multicast, ordering, etc.
The ForCES TML specifications are detailed in separate ForCES The ForCES TML specifications are detailed in separate ForCES
documents, one for each TML. documents, one for each TML.
3. Overview 3. Overview
3.1. ForCES Protocol Framework 3.1. ForCES Protocol Framework
The ForCES protocol document has presented the protocol framework as
in Figure 1. The framework shows the relationship between Protocol
Layer (PL) and Transport Mapping Layer (TML). According to this
framework, TML lies under PL and provides transportation services for
protocol messages to PL. CE PL communicates with FE PL via CE TML
and FE TML. On transmission, PL delivers its ForCES messages to its
TML. The TML further delivers the messages to the destination peering
TML(s). On receive, TML delivers ForCES messages it has received to
its PL.
The ForCES protocol has presented the protocol framework as in +-------------------+ +-------------------+
Figure 1. The framework shows the relationship between PL and TML. | CE PL layer | | FE PL layer |
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 | CE TML layer | | FE TML layer |
+-------------------+ +-------------------+
Hadi Salim Expires Oct., 2006 [Page 3] ^ ^
transmit, the PL delivers its ForCES messages to the TML. The TML | ForCES protocol messages |
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 Figure 1. ForCES Protocol Framework
3.2. TML Requirements 3.2. TML Requirements
The ForCES protocol [ForCES-PL] also presents TML requirements. We The ForCES protocol docuement has also presented TML requirements.
list the requirements as below. These requirements are expected to be We list the requirements as below. Each TML specification must
delivered by TML using any kind of transport media, though the text describe how it contributes to achieving the requirements. If, for
does not define how such mechanisms are delivered. Each TML must any reason, a TML does not provide a service listed by the
describe how it contributes to achieving the requirements. If for any requirements, a justification needs to be provided.
reason a TML does not provide a service listed below a justification
needs to be provided.
The TML requirements are: The TML requirements are:
1. Reliability 1. Reliability
As defined by RFC 3654, section 6 #6. As defined by RFC 3654, section 6 #6.
2. Security 2. Security
TML provides security services to the ForCES PL. TML layer should TML provides security services to the ForCES PL. TML layer should
support the following security services and describe how they are support the following security services and describe how they are
achieved. achieved.
* Endpoint authentication of FE and CE. * Endpoint authentication of FE and CE.
* Message Authentication * Message Authentication
Hadi Salim Expires Oct., 2006 [Page 4]
* Confidentiality service * Confidentiality service
3. Congestion Control 3. Congestion Control
The congestion control scheme used needs to be defined. The The congestion control scheme used needs to be defined. The
congestion control mechanism defined by the TML should prevent the FE congestion control mechanism defined by the TML should prevent the FE
from being overloaded by the CE or the CE from being overwhelmed by from being overloaded by the CE or the CE from being overwhelmed by
traffic from the FE. Additionally, the circumstances under which traffic from the FE. Additionally, the circumstances under which
notification is sent to the PL to notify it of congestion must be notification is sent to the PL to notify it of congestion must be
defined. defined.
skipping to change at line 234 skipping to change at page 5, line 37
supporting up to 8 priority levels does not mean that the underlying 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 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 event the priority levels should be divided between the available TML
priority levels. For example, if the TML only supports 2 priority 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 levels, the 0-3 could go in one TML priority level, while 4-7 could
go in the other. go in the other.
8. Protection against DoS attacks 8. Protection against DoS attacks
As described in the Requirements RFC 3654, section 6 As described in the Requirements RFC 3654, section 6
4. TML Modeling 4. TML Representation
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, The document is to define a set of general services for TML that
TML properties can be abstracted by the following entities: various TMLs and their implementations must fundamentally provide for
ForCES PL layer. For this sake, a TML representation is necessary
that describes general properties of various TMLs. The following
entities are used to represent various TML properties.
TML Events: TML Events:
When the events happen in TML, PL may be interested to be notified.
Hadi Salim Expires Oct., 2006 [Page 5]
The TML events that PL requires to know when the events happen in
the TML.
TML attributes: TML attributes:
The TML attributes that are required to be configured by PL Represent the TML parameters that should be configured by PL when PL
according to PL requirements. The attributes can also be queried by asks TML to provide services.
PL.
TML capabilities: TML capabilities:
The TML capabilities that PL are interested to know. TML abilities or capacities that PL is 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 Note that, not all TML properties should be made perceivable and
properties of variant TMLs. controllable by PL. PL only cares those TML properties that PL should
interact with in order for TML to properly provide services to the PL.
4.1.TML events 4.1.TML events
There might be several TML events, but only some of them are PL must TML events are triggered by some TML status changes when TML is
sense via PL-TML interface. running. PL layer may be interested to be notified when some TML
events occur. TML is responsible to asynchronously notify PL of these
events.
A callback mechanism is defined for PL to sense the TML events by How a TML event is asynchronously notified to PL highly depends upon
PL-TML service primitives. PL first provides every event with a operating system environments PL and/or TML implementations may be
callback function for the event processing in the PL. PL then tells based. As an example, some environments may adopt a callback
the callback handle to TML by service primitives. The callback handle mechanism for notification of events between program processes. In
is usually stored in TML as a parameter. Whenever the relavent event this case and for the PL/TML usage, PL may first construct a callback
happens in TML, the TML triggers the handle to notify PL of the event. function to process every event, and then tell TML the callback
PL executes the callback function, and asynchronously begins to function handle. Whenever an interested event happens in TML, the TML
process the event. will notify PL of the event by invoking the callback handle and let
PL execute the callback function. In this way, the TML asynchronously
passes the event notification to the PL.
After a TML event happened and PL is notified and a procedure to However, this document does not try to define specific means for
process the event is executed, PL may be further interested in PL/TML notification. Any appropriate means can be adopted under
knowing if the event status in the TML still exists or not. To meet condition that it shall meet the service requirements.
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.
The following TML events must be made to be notified by PL. If for A TML event may appear as a sustained event, i.e., the event will
any reason a TML does not provide the service, a justification needs last until the condition triggered the event is changed and the event
to be provided in the TML specification. is then released. For instance, when an error happens in TML, it will
last until the error is finally by any means removed. In the
sustained event case, PL may be interested in knowing not only when
the event takes place, but also when the event is released. To meet
this need, an event status parameter should be defined and associated
with a sustained event report. The parameter will mark the associated
event with either 'occurring' or 'is released' to indicate the two
different status of a sustained event. Nevertheless, not all events
are sustained events, so that not all event reports need this kind of
parameters.
1) TML failure event A TML event shall be distinguished as being subscription-free or
subscription-requested. A subscription-free TML event will inevitably
be notified to PL when it occurs. A subscription-requested TML event
is only notified to PL when it has been subscribed for by the PL. A
way for PL to subscribe for a subscription-requested TML event will
be provided by defining an event handle TML attribute as in 1) of
Section 4.2. The TML attribute can also provide more events
parameters configuration. See Section 4.2 for more details on the
attribute definition.
This event happens when there is a TML failure. It is up to An TML event is assigned a TML event id, so that PL can identify the
individual TML specifications and even individual implementations to event uniquely.
Hadi Salim Expires Oct., 2006 [Page 6] Followed are descriptions of TML events that must be available for
specify the detailed event triggering conditions, but usually, TML all TML specifications. If, for any reason, an individual TML
failure should include the following cases: specification does not provide the events, a justification needs to
. local TML link failure be provided in the specification.
. peer TML unavailable
. peer TML left
The different cases that cause the failure will be stated by a 1) TML error event
failure code in the event callback function.
Callback handle for TML failure event is then defined as: This event reports a TML error during TML running to PL. When the
event is invoked, something might be wrong in the TML. Failures like
TML link failure in TML are also taken as TML errors, which can be
understood as fatal errors for some cases.
status = -- SUCCESS or errorIndication When the event occurs and an event report is notified to PL, an
callbackTMLFailureEvent( error code is associated with the event report so as to pass more
IN eventState information about the error to PL layer. The code may expose PL the
IN failCode reason of the error, the type of the error, as such.
)
Where,
eventState = EventHAPPENED or EventRELEASED
failCode indicates the failure case
2) Message arrival event TML error event is a subscription-free event. When the event occurs,
it will always invoke a report to PL.
TML can make it as an event when a PL ForCES protocol message coming TML error event is a sustained event. The error status will last
from peering TML arrives at the TML and the TML has made it ready for until the error is removed by any means.
PL to receive the message. In this way, an asynchronous message
As a result, when the event is notified to PL, the following
information shall be associated with the event report:
o TML error code and associated data
o event status
1 The event is occurring
0 The event is released
Note that it is not restricted that more information may also be
associated with the event report, depending upon each TML
specification or implementation.
This document defines the following TML errors and associated data.
These errors are usually common to all types of TMLs.
TML error code TML error Associated Data
1 all local TML link failure none
2 some local TML link failure peer TML CE/FE ID(s) the
link is connected
3 peer TML unavailable peer TML CE/FE ID(s)
4 peer TML abnormally left peer TML CE/FE ID(s)
Each TML specification may define its specific errors. There is also
a room for each TML implementation to define specific errors.
TML error event is assigned with a TML event id = 1.
2) Message arrive event
TML shall be able to make it as an event occurrence when it has
received a PL ForCES protocol message from peer TML and has made it
ready to deliver to local PL. In this way, an asynchronous message
receive mode can be realized in PL. In addition to this asynchronous receive mode can be realized in PL. In addition to this asynchronous
mode, PL can also use a specific TML receive service primitive mode, PL can also use a specific TML receive service primitive as
(defined below) for synchronous reception of PL messages. defined in Section 5.8 for PL synchronous receiving of ForCES
messages.
Callback handle for message arrival event is defined as: This event is a subscription-requested event, i.e, unless PL has
requested TML to do so, TML will not use an asynchronous event
notification way to deliver arrived messages to PL. In this case, PL
can still use a TML receive primitive to receive ForCES messages.
status = -- SUCCESS or errorIndication When the event is notified to PL, the following information shall be
callbackTMLMsgArrivalEvent( associated:
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 o the arrived ForCES message length
ForCES control messages are defined as all ForCES protocol messages o the whole arrived ForCES message Protocol Data Unit (PDU)
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 It is not restricted that other information might also be associated
control message transmission. It is up to individual TML with this event report, depending upon requirements of individual TML
specifications or implementations.
Hadi Salim Expires Oct., 2006 [Page 7] Note that the message arrive event is not a sustained event, and
specifications and even individual implementations to specify the there is no need to distinguish its status as occurring or released.
detailed event triggering conditions. When the message is reported to PL, the event is automatically
released.
This event can be used by PL layer to monitor the control message TML message arrive event is assigned with TML event id = 2.
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 3) TML congestion alert
as:
status = -- SUCCESS or errorIndication Although it is expected that TML provide a ForCES message
callbackTMLCtrMsgCongestEvent( transportation free of congestion, as a general problem for current
IN eventState Internet society, congestion problem is still quite hard to be
) completely avoided if mechanisms are purely limited in TML resources
Where, and without help from PL resources. In many cases, with the help from
eventState = EventHAPPENED or EventRELEASED the resources in PL layer, congestion problem may be much better
suppressed. For example, in cases where the OS a TML adopts is
capable of detecting an ECN (Early/explicit congestion notification)
where the underlying IP protocol is capable of passing information to
the application, then the TML could pass such information to the PL.
The PL could use this information for example to adjust its sending
rates or increase or reduce the priority of certain PL messages, etc.
More over, even in the case PL could help little for TML congestion,
it is still very helpful for PL to know the TML congestion state if
it does happen. As a result, in the TML requirement in Section 3.2,
it is required that TML must be defined with a method to notify PL of
congestion state.
4)Redirect message congestion event This document specifies that a TML congestion alert event must be
supplied with various TMLs and their implementations if the TMLs and
implementations are not free from congestion problems due to any
reasons. TML notifies PL of congestion state by this TML congestion
alert event. It is an alert event because we expect that TML notifies
PL of the event when TML is in danger of, rather than in the state of,
congestion. An alert event is more helpful, because TML is the only
path that an FE is connected to CE, and a complete congestion state
in TML may lead to CE lost control of the FE, which is fatal for the
FE.
This event happens when the TML comes to a congestion state for the A TML congestion alert event is defined as a subscription-requested
PL redirect message transmission. It is up to individual TML event. It means PL will subscribe for it if PL requires the
specifications and even individual implementations to specify the congestion alert. During some usage cases or during some period of
detailed event triggering conditions. usage, PL may not be interested to be notified of such event. For
instance, in many cases, congestion problem at CE side are not so
serious as that at FE side where FE side often risk DoS attacks from
redirect data. In this case, CE side congestion alert event may be
turned off so as to save CPU resources, while FE side congestion
alert is always open.
This event can be used by PL layer to monitor the redirect message A TML congestion alert event is a sustained event. When congestion
transmission. In FEs, this may also be used to help monitoring alerts, it will last until its state is changed back to free of
possible DoS attacks from redirect packets. danger for congestion. TML should notify PL twice for the whole
congestion report. When there is a congestion alert, TML sends one
notification to PL, when it is released, TML sends another
notification to PL.
Callback handle for TML redirect message congestion event is defined TML congestion alert event is assigned with TML event id = 3.
as:
status = -- SUCCESS or errorIndication When the event is notified to PL, the following information will be
callbackTMLRedMsgCongestEvent( associated with its report:
IN eventState
)
Where,
eventState = EventHAPPENED or EventRELEASED
5)DoS attack alert event o TML congestion alert type
1 congestion alert from control message transmission
2 congestion alert from redriect message transmission
3 alert from redirect DoS attack
o event status
1 The event is happening
0 The event is released
Note that it is not restricted that other information may also be
associated with the congestion alert report, depending upon
individual TML specifications or implementations. For instance, in
several cases, it may be of great help to associate with some extra
information as which CE/FE link is the congestion located. However,
it may be quite difficult for all TMLs and implementations to provide
such information, therefore, as a more suitable choice, it is just
left each TML or implementation to decide.
This event happens when the TML comes to a state that it feels there More specific definitions of the three types of TML congestion alerts
are abnormal amount of PL redirect messages and there has made it are presented as below:
quite hard to transport PL control messages. Whereas, it is up to
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 1. Congestion alert from control message transmission
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
Hadi Salim Expires Oct., 2006 [Page 8] We define that ForCES control messages are all kinds of ForCES
event is an alert, when it happens, usually it does not mean the CE- protocol messages but ForCES redirect messages. ForCES message types
FE communication is totally lost. are identified by the message type in the ForCES message header.
ForCES redirect messages are the messages whose types are marked as
'PacketRedirect'[ForCES-PL]. ForCES redirect messages are used to
load redirect data between FE and CE.
Callback handle for TML DoS attack alert event is defined as: Congestion alert from control message transmission indicates that TML
is in a state where control message transmission channel is in danger
of congestion and control messages is becoming hard to be transmitted
to peering TML(s). Individual TML specifications or implementations
may specifically define the detailed invoking state for the alert.
status = -- SUCCESS or errorIndication Because ForCES control messages are vital for ForCES network elements
callbackTMLDoSAttackAlertEvent( to properly work, the congestion alert from control message
IN eventState transmission is an important signal for PL to timely take actions to
) secure the network element.
Where,
eventState = EventHAPPENED or EventRELEASED 2. Congestion alert from redirect message transmission
This congestion alert is invoked when the TML comes to a risk that
redirect messages are congested during transmission. Each TML
specification or implementation may specifically define the detailed
invoking state for the alert.
ForCES redirect messages that load redirect data between FE and CE,
congestion of which may not be so harmful as that of ForCES control
messages, but some redirected data are still vital for ForCES network
elements to properly work. For instance routing protocol messages
are shipped via ForCES redirect messages. A long time congestion of
the messages will severely affect actions of routing protocols. Hence,
this congestion alert should be used by PL to avoid redirect message
congestion as much as possible to improve performance of whole
network elements.
3. Alert from redirect DoS attack
As described, ForCES redirect messages ship redirect data. In FEs,
redirect data come via FE interfaces from outer networks. This may
leave a hole for malicious attackers [RFC3654, RFC3746]. Attackers
may try to start a DoS attack by initiating huge amount of redirect
data to some specific ForCES CE. It may make some FE TML abnormally
busy transporting redirect data. Because TML channels for ForCES
redirect messages and ForCES control messages are often intervened in
many TML implementations in the same physical links, it may
eventually making control messages transmission blocked by redirect
messages transmission, making the network element in a denial of
service state.
This alert is used to indicate an alert for redirect DoS attack. Each
TML specification or implementation will specifically define the
actual invoking state or take a mechanism for the alert to be invoked,
or make a justification if the TML is considered free from such DoS
attack. If a TML has taken some specific mechanism to make
straightforward detection of DoS attacks from redirect data, this
alert may just be a result report of the DoS detection.
The TML alert from redirect DoS attack may not be sufficient enough
for the PL to assure the DoS attack state. PL may synthesize
information from other part of the FE, like information from some FE
LFBs, to finally decide it. Whereas, this alert has already been an
enough signal for PL to go into some urgent state for the whole
system security. Approaches should be taken immediately by PL to try
to release the alert state so that the FE is not in a risk of losing
control from CE.
4.2.TML attributes 4.2.TML attributes
1) Event handles TML attributes usually represent those TML parameters that need to be
configured by PL. To represent them as TML attributes, PL can then
use TML configuration service primitive as defined in Section 5.5 to
make operations to the parameters. PL can then also use TML query
service primitive defined in Section 5.6 to retrieve the status of
the parameters.
Event handles are handles for PL to access events. An event callback Every TML attribute shall be assigned with a unique id for PL to
function handle is used as the purpose. Defining the handles as an identify the attribute. The id is called TML attribute id.
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: Followed are descriptions of basic TML attributes that shall be used
by all TMLs. Each TML or implementation may provide more detailed
definitions of these TML attributes based on the basic descriptions.
Individual TMLs or implementations are also allowed to define more
specific TML attributes on their own if necessary.
<dataTypeDef> 1) TML event handle
<name>Eventhandle</name> This TML attribute is used for PL to set some parameters for
<synopsis>Event callback handle</synopsis> individual TML events. Each TML may individually define its data
<struct> structure for this attribute, whereas, the data structure may have to
<element elementID="1"> appear as a list and every element of the list may have to at least
<name>eventType</name> include the following information:
<synopsis>event type represented by an ID </synopsis>
<typeRef>uint16</typeRef>
<specialValues>
<specialValue Value="1">
<name>TMLFailureEvent</name>
<synopsis>TML failure event</synopsis>
</specialValue>
<specialValue Value="2">
<name>TMLMsgArrivalEvent</name>
<synopsis>TML ForCES message arrival event</synopsis>
</specialValue>
<specialValue Value="3">
<name>TMLCtrMsgCongestEvent</name>
<synopsis>
TML ForCES congtrol message transmit congestion event
</synopsis>
</specialValue>
<specialValue Value="4">
<name>TMLRedMsgCongestEvent</name>
<synopsis>
Hadi Salim Expires Oct., 2006 [Page 9] o TML event id
TML ForCES redirect message transmit congestion event This id acts as an index for individual TML events.
</synopsis>
</specialValue>
<specialValue Value="5">
<name>TMLDoSAttackAlertEvent</name>
<synopsis>TML DoS attack alert event</synopsis>
</specialValue>
</specialValues>
</element>
<element elementID="2">
<name>handle</name>
<synopsis>callback function handle of the event</synopsis>
<typeRef>uint64</typeRef>
</element>
</struct>
</dataTypeDef>
<attribute access="read-write" elementID="1"> o subscription flag, if described is a subscription-requested TML
<name>EventHandles</name> event
<synopsis>event handle table in the TML</synopsis> This flag is to indicate the state for TML event subscription. To
<array> subscribe/unsubscribe an event is to set/reset the flag.
<typeRef>EventHandle</typeRef>
</array>
</attribute>
2)multicast lists The attribute may also include other information for each TML event
implementation. For instance, for an implementation that adopts a
callback mechanism for event notifications, the attribute may include
a callback handle, which is used for PL to tell TML the callback
function handle.
This attribute is used for TML to multicast ForCES messages. The The 'TML event handle' is assigned with a TML attribute id = 1.
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 2) Multicast list
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 ForCES protocol requires that TML must support for ForCES message
multicast applications. The multiple multicast lists form a multicast delivery in multicast ways. This multicast is defined at ForCES PL
list table in TML. level, i.e., to multicast a ForCES protocol message, a multicast
'Destination ID' at the ForCES message header will be specified (See
[ForCES-PL] for more details). To support the PL level multicast, TML
must be told the members of the multicast, so that the TML can
accordingly deliver messages to all the multicast members. A
multicast list is used for this purpose. The multicast list comprises
a multicast id, which is exactly the multicast 'Destination ID', and
numerous associated members, which are also represented by ForCES
'Destination ID's, represented as below:
The attribute for the multicast lists is defined as below: multicast list = {multicast id, member1, member2, ... memberN}
}
<dataTypeDef>
<name>McastList</name>
<synopsis>
a PL level multicast list for ForCES multicast transport
</synopsis>
<struct>
<element elementID="1">
<name>groupID</name>
Hadi Salim Expires Oct., 2006 [Page 10] When TML is told this multicast list, it means whenever TML is asked
<synopsis>32bits group ID of the multicast</synopsis> by PL to send a ForCES message whose Destination ID is this multicast
<typeRef>uint32</typeRef> id, the TML must deliver the message to all destination CEs or FEs
</element> whose ids are individually represented by member1, member2, ... , and
<element elementID="2"> memberN. Individual TML specifications should define how such
<name>members</name> multicast list maps to TML transport level multicast mechanisms. For
<synopsis> instance, if TML adopts multiple TCP links for this PL level
members of the multicast represented by FE ID or CE ID multicast, every member in the multicast list may be mapped to a
</synopsis> specific TCP port and an associated IP address. If TML adopts UDP
<array> multicast for this PL level multicast, a UDP multicast group with the
<typeRef>uint32</typeRef> same numbers may be constructed and the multicast is mapped to the
</array> UDP multicast group.
</element>
</struct>
</dataTypeDef>
<attribute access="read-write" elementID="2"> The multicast list must be set into TML by PL, hence it is defined
<name>McastLists</name> as a TML attribute. PL sets up the attribute by use of a TML
<synopsis> configuration service primitive.
a table representing several multicast lists in the TML
</synopsis> There might be several multicast lists set to a TML so as to
<array> construct multiple multicast paths for PL in this TML. The multicast
<typeRef>McastList</typeRef> lists may form a table then in the TML. In this case, a multicast id
</array> in every multicast list may act as an index for access of the table.
</attribute>
The 'TML multicast list' is assigned with a TML attribute id = 2.
3) Working TML Type 3) Working TML Type
A TML implementation may be capable of several TML transport ways. A TML implementation may be capable of several TML transport ways.
For example, a TML with IP transport media may be able to support For example, a TML with IP transport media may be able to support TML
several transport protocols, like TCP+UDP, TCP+DCCP, SCTP, etc. In schemes as TCP for control messages transmission and DCCP for
this case, there should be a TML attribute describing the different redriect message transmission, or TCP for control messages and UDP
types and make PL able to switch among the types under the control of for redirect messages. In this case, it may be helpful for PL to
CE. dynamically specify which TML transport scheme to adopt for current
work.
The TML type is represented by an ID, defined as below: The working TML type is used for above purpose. It is defined as an
TML attribute.
<dataTypeDef> It should be noted that, in many cases, PL does not have to manage
<name>TMLType</name> working TML type. TML may more rely on its own management tool or a
<synopsis>TML Type</synopsis> CE/FE manager for TML type management. As a result, this TML
<atomic> attribute is defined as an optional TML attribute, i.e., it is
<typeRef>uint16</typeRef> allowed that a TML may not provide this TML attribute for PL.
<specialValues>
<specialValue Value="1">
<name>TmlTcpUdp</name>
<synopsis>TML uses TCP+UDP</synopsis>
</specialValue>
<specialValue Value="2">
<name>TmlTcpDccp</name>
<synopsis>TML uses TCP+DCCP</synopsis>
Hadi Salim Expires Oct., 2006 [Page 11] Whereas if the attribute is provided, it should include the
</specialValue> following information:
<specialValue Value="3">
<name>TmlSctp</name>
<synopsis> TML uses SCTP</synopsis>
</specialValue>
<specialValue Value="4">
<name>TmlEth</name>
<synopsis>TML uses Ethernet</synopsis>
</specialValue>
<specialValue Value="5">
<name>TmlAtm</name>
<synopsis>TML uses ATM</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
The TML attribute for the working TML type is defined as below: o Working TML Type id
the TML type represented by an id, which is set to the TML for it
works in this type. The TML type id may be assigned with one of the
following values:
1 - an IP TML type with the protocol scheme as TCP+UDP, i.e., TCP
for control message transmission and UDP for redirect data
transmission.
2 - an IP TML type with the protocol scheme as TCP+DCCP, i.e., TCP
for control message transmission and DCCP for redirect data
transmission.
3 - an IP TML type with the protocol scheme as SCTP, i.e., SCTP for
both control and redirect data transmissions.
4 - an Ethernet TML type
5 an ATM based TML type
The 'Working TML type' is assigned with a TML attribute id = 3.
<attribute access="read-write read-only" elementID="3"> 4) TML media specific attributes
<name>WorkingTMLType</name>
<synopsis>current working TML type assigned by PL </synopsis>
<typeRef>TMLType</typeRef>
</attribute>
Note that, the working TML type attribute may be configurable or may An individual TML specification may require PL to configure some
only be readable depending on implementations. TML capability on the extra TML parameters specific to this TML media. If any, the TML
TML type (defined below) will tell if it is configurable or not. To specification shall provide detailed definitions for such attributes.
query the TML type capability before configuring the working TML type
attribute will help to correctly configure it.
4) Media specific TML parameters 5) Implementation specific TML attributes
Individual TML may require configuring some TML parameters specific An individual TML implementation may require PL to configure some
to its TML media. There leave a space in TML service primitives for TML parameters specific to this implementation. If any, the
such requirement. Individual TML specifications should provide individual implementation will provide detailed definitions for such
detailed definitions for such parameters. attributes.
5) Vendor specific TML parameters 4.3. TML capabilities
Vendors of individual implementations of TML may require configuring TML capabilities represent TML abilities or capacities to provide
some TML parameters specific to its implementation. There leave a services to PL. A TML capability can only be read by PL via TML query
space in TML service primitives for such requirement. Individual service primitive.
implementation should provide detailed definitions for such
parameters.
4.3. TML capabilities Note that, the TML query service primitive as described in Section
5.6 is used to query status of TML attributes as well as TML
capabilities. A TML attribute id or a TML capability id is
simultaneously used for the query operation. As a result, TML
attribute id and TML capability id should be kept harmonious and
unique to each other.
1) Supported TML type 1) Supported TML type
Hadi Salim Expires Oct., 2006 [Page 12] PL may be interested to know what TML transportation type(s) the
A TML implementation may be capable of several TML transport ways. associated TML can support. A TML implementation may be capable of
This capability indicates PL of the supported types. only one TML transport type or simultaneously several TML transport
types. This TML capability indicates the relative information to PL.
The TML capability for the supported TML type is defined as below: Note that, as mentioned before, in many cases, PL does not have to
manage TML types. TML may more rely on its own management tool or the
CE/FE managers for TML type management. As a result, this capability
is defined as an optional TML property, i.e., it is allowed some TML
implementations may decide not to provide this information to PL.
<capability elementID="4"> Whereas, if the capability is provided, it should include the
<name>SupportedTMLType</name> following information:
<synopsis>supported TML types in the TML mechanism</synopsis>
<array type="variabl-size">
<typeRef>TMLType</typeRef>
</array>
</capability>
2) TML type configuration capability o a list of supported TML Type id(s)
the TML Type id is as defined before.
o configurable indicator
a flag to indicate if the TML is configurable or not for its
working type, i.e., if PL can use a working TML type attribute to set
the type to the TML.
<capability elementID="5"> The 'Supported TML type' capability is assigned with a TML
<name>TMLTypeConfigurable</name> capability id = 10.
<synopsis>TML Type configurable or not by PL </synopsis>
<typeRef>boolean</typeRef>
</capability>
5. Service Primitives 5. TML Service Primitives
5.1.Design Principles 5.1.Design Principles
Two principles are applied to this PL-TML service primitives design: The following principles are applied to the PL-TML service
primitives design:
1.PL-TML service primitives should hide implementation details 1.PL-TML service primitives should hide implementation details
regarding reliability, security, multicast, congestion control, etc regarding reliability, security, multicast, congestion control, etc
from PL. from PL.
2.PL-TML service primitives should avoid leading TML to read ForCES 2.PL-TML service primitives should be decoupled from possible
protocol message PDU to get information, so as to immunize the TML changes of ForCES PL layer such as the update of ForCES protocol and
from the possible change of ForCES protocol PDU (like the protocol ForCES FE model. More specifically, primitives should be avoided to
update). be coupled with ForCES protocol PDU format.
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.
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 5.2. TML Open
Syntax: Format:
Result = TMLopen( )
Hadi Salim Expires Oct., 2006 [Page 13] Result:
status = -- SUCCESS or errorIndication the returned result; it shall indicate whether the TML open is
TMLopen( ) succeeded or not. Moreover, if not succeeded, an id called 'TML id'
and used to identify the TML should be returned by the primitive. If
not succeeded, an error code may be returned to indicate the error
type.
Parameters: Parameters:
none none
Service Description: Service Description:
The PL connects to the TML by invoking the TML open call. It highly The primitive is for PL to indicate a TML that the PL is going to
depends on the individual TML specifications what a TML should do associate itself with the TML for services and hence the TML should
after receiving this call. For some TMLs, this primitive call may be ready for use. It highly depends upon each TML specification or
only act as a signal to inform TML that PL is going to use the TML individual implementations on what a TML should do when it receives
for sending or receiving PL messages, while for some other TMLs, a this primitive. For some TMLs, this primitive may just act as an
TML may have to do some TML level operation to prepare for PL usage indicator that the PL and the TML has been associated, while every
when receiving this primitive call. For example, For a connectionless thing for providing services has already been there in the TML. For
TML, this open primitive may does not have to do anything, while for other TMLs, when received the primitive, they may have to do
a connection-oriented TML, this open call may be a signal for the TML something to make it ready. For example, for a TML that adopts a
to setup TML level connection(s) to peering TML(this actually means connectionless path as one of its transmission path, the path may
the peer-to-peer TMLs do not have to always be connected after the always be ready for message transportation without any extra setup;
TML is initialized and during the post-association phase). while for a connection-oriented TML path, a TML open or a TML close
(see below) primitive may act as an indicator for the TML path to be
set or reset. However, it is also possible that some TML
specifications or implementations may choose to have such connection-
oriented path always ready for use when the TML has been initially
booted.
Another important point is, to better synchronize the operations The 'TML id' returned by this primitive is as an identifier for the
between peering PLs, the TML will have to discard all the PL messages PL to recognize the TML. Other primitives as described below will use
received from peering PL before the local TML has not yet been opened this id to identify a TML for operations. Having defined the TML id,
by the local PL, we imply that the usage scenario as one PL being associated with more
than one TML will not excluded by any TML specifications, and may be
applied in actual implementations.
5.4. TML close An important note is, to better synchronize the operations between
peering PLs, if a TML has, for any reason, received any PL messages
from peering PL before local PL has formally opened the TML, the TML
shall discard all these messages.
Syntax: 5.3. TML close
status = -- SUCCESS or errorIndication
TMLclose( ) Format:
Result = TMLclose(
TML id
)
Result:
the returned result; it shall indicate whether the TML close
operation is succeeded or not. Moreover, if succeeded, an error code
may be returned to indicate the error type for the failed TML close.
Parameters: Parameters:
none o TML id (input)
the id of the TML to be closed.
Service Description: Service Description:
In this call, the PL disconnects from the TML. It highly depends on By this primitive, a PL tears down its association with a TML. It
the individual TML specifications what a TML should do after highly depends upon each TML specification or implementation on what
receiving this call. For some TMLs, this primitive call may only act a TML should do when received this primitive. For some TMLs, this
as a signal to inform TML that PL is not going to use the TML for primitive may just act as an indication that the association of the
sending or receiving PL messages anymore, while for some other TMLs, PL and the TML is terminated and nothing more need to be done. For
a TML may have to do some extra TML level operations to disconnect it other TMLs, when received the primitive, they may have to manage to
to peering TMLs. For example, for a connectionless TML, this make it terminate the association, e.g., by disconnecting a
primitive may do not have to do anything, while for a connection- connection with peering TML. However, it is out of scope of this
oriented TML, this primitive call may be a signal for the TML to document to have more details specified.
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.
Hadi Salim Expires Oct., 2006 [Page 14] An important note is, to better synchronize the operations between
peer PLs, if a TML has, for any reason, received any PL messages from
peer PL after local PL has formally closed the TML, the TML shall
discard all these messages.
5.5.TML Configuration 5.4.TML Configuration
Syntax: Format:
status = -- SUCCESS or errorIndication Result = TMLconfig(
TMLconfig( TML id,
IN operation operation type,
IN path TML attribute id,
IN data TML attribute data
[,optional parameters]
) )
Result:
the returned result; it shall indicate whether the TML configuration
is succeeded or not. Moreover, if not succeeded, an error code may be
returned to indicate the error type for the failed configuration.
Parameters: Parameters:
o TML id (input)
the id of the TML to be configured.
o operation type (input)
As an input parameter, it specifies the operation type the TML
configuration primitive will do. The following operations must be
included:
SET to set data to an attribute in the TML
DELETE to delete data from an attribute in the TML or to
totally remove the attribute from the TML.
The following operation may be included:
MODIFY to modify data for an attribute in the TML
operation ?the operation type for the configuration. Two operations Individual TMLs or implementations may define other operations if
are defined: necessary.
operation = ADD ?to add parameter
= DELETE ?to delete parameter
path ?a path composed of element ID(s) and (or) array index o TML attribute id (input)
pointing to the element to be configured. the id inputted to TML; it uniquely specifies the TML attribute
(TBD) the primitive is going to operate on. The id is assigned by
individual TML attribute definitions.
data ?the data to be configured to the element. o TML attribute data (input)
(TBD) a data unit that contains data elements to be configured to a TML
attribute. Actual data structure of the data unit will be defined by
individual TML implementations.
o optional parameters (input or output):
Individual TMLs or implementations may allow more parameters for
the TML attribute configuration. For e.g., some implementations may
choose to take an extra timeout parameter to make the primitive as a
non-blocking primitive call. This document does not exclude such
usages.
Service Description: Service Description:
This primitive is used by the PL to control the behavior of the TML This primitive is used by PL to configure attributes of TML
by the PL layer configuring the related property elements in the TML. according to service requirements made to the TML. TML attributes are
The element is indicated by the 'path'. The value to be configured to basically described as in Section 4.2. Every attribute to be operated
the element is accessed by the 'data'. is identified by the TML attribute id. The TML attribute data
parameter provides necessary data for the operation. It is up to
individual TML implementations to specify data structure for the
attribute. It may be organized as an atomic data element or a
compound data element. Individual TML implementations should provide
detailed description on the data structure used for individual TML
attributes.
5.6. TML Query SET or DELETE operations are two basic operation types to a TML
attribute operation. In some cases, more operation types may be
required so that management to TML attributes may become more
portable to users. This is especially useful for management of TML
attributes like TML multicast lists. When PL configures multicast
lists to TML, it may require some form of operation variations
besides general operations as setting a new multicast list or
deleting an existing multicast list. For instance, PL may be
interested to add a member to, or delete a member from, an existing
multicast list. There may be two approaches for each TML
implementation to realize this. One is to define more types of
operations. The other is to specifically associate attribute data
structure definitions with operation types. Below is an example to
show that this is feasible:
Syntax: o operation = SET, data = {multicast id, member1, member2, ...}
status = -- SUCCESS or errorIndication If the multicast list with the multicast id does not exist in
TMLquery( the TML, it is to set a new multicast list, or else, to add the new
IN path members as listed to the existing multicast list.
OUT data
o operation = DELETE, data = {multicast id }
to delete the whole multicast list with the multicast id.
o operation = DELETE, data = {multicast id, member1, member2, ...}
to delete the members as listed from an existing multicast list,
while keeping the multicast list id.
Note that the TML configuration service primitive is not designed to
return any attribute status after configured. To check the TML
attribute status, a TML query primitive as defined below should be
specifically used.
5.5. TML Query
Format:
Result = TMLquery(
TML id,
TML attribute id or TML capability id,
[,optional parameters]
) )
Result:
The result includes a returned result and a queried result;
The returned result shall indicate whether the primitive operation is
succeeded or not. Moreover, if not succeeded, an error code may be
returned to indicate the error type for the failed query operation.
The queried result shall include the queried data if the query
operation is succeeded. Each TML implementation shall define the data
structure for the queried result data. Each TML attribute or TML
capability may all have its specific data structure.
Note that it is not specified and restricted how the queried result
should be implemented in reality. Any techniques may be applied for
this purpose under condition that the queried data can be transferred
back to PL layer. For instance, some implementations may adopt a
return of function call for transferring the queried result data,
while some others may just adopt a parameter of function call for the
transferring.
Parameters: Parameters:
o TML id (input)
the id of the TML to be operated.
path ?a path composed of element ID(s) and (or) array index o TML attribute id or TML capability id (input)
pointing to the element to be queried. the id that uniquely specifies the TML attribute or TML capability
(TBD) the primitive is going to query.
data ?the data returned by the query. o optional parameters (input or output):
(TBD) Besides the mandatory parameters as presented, individual TMLs or
implementations may adopt more parameters to customize the query
operation. For instance, it may be interested to query a multicast
list with a specified multicast id, rather than to query the whole
existing multicast lists. This may be realized by defining a
parameter composed of a multicast id as an index for the query. The
primitive may also include a timeout parameter to make the primitive
as a non-blocking operation. This document does not exclude such
usages.
Service Description: Service Description:
This primitive is used by PL to query TML attributes or TML
capabilities to know their current status. The TML attribute id or
TML capability id is used to specify which attribute the primitive is
interested to query. Queried data are included in result of the
primitive execution. Note that this primitive definition does not
specify any technology on how the queried data shall be transferred
from TML to PL, so as to make the primitive definition independent of
any specific OS environments or implementation techniques.
Hadi Salim Expires Oct., 2006 [Page 15] 5.6. TML send
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: Format:
status = -- SUCCESS or errorIndication Result = TMLsend(
TMLsend( TML id,
IN msgDestID, message destination id,
IN msgType, message type,
IN msgPrio, message priority,
IN msgLength, message length,
IN msgPDU, message PDU
[, timeout]
[, more optional parameters]
) )
Result:
a returned code indicating if the TML send primitive is successful
or failed. If successful, a success code is returned. If failed, an
error code indicating the failure type is returned.
Parameters: Parameters:
msgDestID: the destination ID for the PL message to be sent o TML id (input)
msgType: the message type for the PL message to be sent the id of the TML to be operated.
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: o message destination id (input)
In this service, the PL sends a message to one (unicast) or more the id indicating the destination of the ForCES PL message to be
(multicast) peer PLs via the TML. Note that this primitive includes sent; equal to the destination ID in the protocol message header.
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 o message type (input)
addresses for the message transmission. It also includes the the type of the ForCES protocol message to be sent; equal to the
processing for PL message multicast transports, for the destination message type in the protocol message header.
ID may also be a multicast group ID.
The msgType is used for the TML to infer the requirements from PL o message priority (input)
level for the manage sending, regarding its reliability, timeliness, the message priority of the protocol message to be sent; equal to
security, and congestion control. With this message type, it is easy the priority bits in the protocol message header.
to recognize PL redirect messages from PL control messages.
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 o message length (input)
message transmission priority; it may also be used for TML to meet the ForCES protocol message length to be sent, equal to the
the TML requirements for reliability, timeliness, security, and message length field in the protocol message header, representing the
congestion control. Individual TML specifications should define how whole protocol message length in DWORDS ( 4 bytes) units.
Hadi Salim Expires Oct., 2006 [Page 16] o message PDU (input)
the priority is mapped into the TML transport mechanisms for Protocol Data Unit for the whole ForCES protocol message,
prioritized transmission. Individual TML specifications may also including the message header and the body. Individual implementations
define how the priority is used for other TML requirements. may need to further specify the endian way (big-endian or little-
endian, etc).
5.8. TML receive o timeout (input, optional parameter)
This is an optional parameter to optionally specify the primitive
as a non-blocking primitive call. The timeout value specifies how
long it may wait before abortion of the primitive call. If not
adopted, the primitive is executed in a blocking way.
Syntax: o other optional parameters
status = -- SUCCESS or errorIndication Individual TMLs or implementations may specify more optional
TMLreceive( parameters if necessary.
IN msgLength,
IN msgPDU, Service description:
By this service, PL tries to send a message to one (unicast) or more
(multicast) peer PLs via the TML. Note that this primitive has
explicitly included all information that are necessary for TML to
manage transmission of the PL message, therefore, there is no need
for the TML to further retrieve more information by reading the PL
message body PDU. In this way, it may be decoupled of changes in
ForCES protocol PDU (e.g., by the protocol update) from TML services.
The message destination id is used by the TML to map to TML layer
transport addresses for the message transmission. This also includes
the mapping of PL layer multicast ids to TML layer multicast
addresses. Each TML specification should define the way for such
mapping.
The message type is used for the TML to infer the requirements from
PL level for the message transmission, regarding its reliability,
timeliness, security, and congestion control. With this message type,
it is easy to recognize PL redirect messages from PL control messages.
Individual TML specifications shall define how the message types are
mapped to their individual transportation resources.
The message priority 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 requirements for reliability, timeliness, security, and
congestion control. Individual TML specifications may define how the
priority is mapped to their available transport mechanisms for
prioritized timely transmission. Individual TML specifications may
also define how the priority is used for other TML requirements.
By use of an optional timeout parameter, the primitive may be
applied either in a blocking way or a non-blocking way.
5.7. TML receive
Format:
Result = TMLreceive(
TML id,
message length,
message PDU,
timeout,
[, optional parameters]
) )
Result:
a returned code indicating if the TML receive primitive is
successful or failed. If successful, a success code is returned. If
failed, an error code indicating the failure type is returned.
Parameters: Parameters:
msgLen: the length of the message received. o TML id (input)
msgPDU: the received ForCES protocol message body in its PDU the id of the TML to be operated.
format
Service Description: o message length (output)
This service is used for PL to synchronously receive PL messages the length of the received ForCES protocol message, representing
from peering TML. the whole protocol message length in DWORDS ( 4 bytes) units. It is a
parameter output to PL by TML via this primitive.
Note that a PL message arrival event described before can also be o message PDU (output)
Protocol Data Unit for the whole ForCES protocol message received,
including the message header and the bogy. Individual implementations
may need to specify the endian way (big-endian or little-endian, etc).
It is a parameter output to PL by TML via this primitive.
o timeout (input)
This is a mandatory parameter for the TML receive primitive. It
mandates that the primitive shall work in a non-blocking way. The
timeout value specifies how long it will mostly wait before abortion
of this time receiving process.
o optional parameters (input or output)
Individual TMLs or implementations may specify more optional
parameters for the primitive if necessary.
Service description:
This service is used for PL to synchronously receive ForCES protocol
messages from peering TML via local TML. A received protocol message
is returned via the parameters. The primitive specifies that it
should be implemented in a non-blocking way. It is because that
usually such receiving process may take high priority resources and a
blocking way may make the system risk more of fatal errors.
Note that a message arrive event as described before can also be
used for PL to receive PL messages from TML. The difference is that used for PL to receive PL messages from TML. The difference is that
this TML receive primitive makes PL to synchronously receive messages, this TML receive primitive makes PL to synchronously receive messages,
while a PL message arrival event receives messages in an asynchronous while a message arrive event works in an asynchronous way receiving a
way. Usually, an asynchronous method is more efficient in terms of message. Usually, an asynchronous method exploits more efficiency in
CPU cycles. terms of CPU resources.
6. Theory of Operation 6. Operation Notes
1) multicast
(TBD) In a ForCES architecture, PL level multicast may be most commonly
for a CE to multicast a ForCES protocol message to multiple FEs.
Operation steps for the ForCES system to setup this type of multicast
may be presented as below:
7. References a. Before a PL level multicast could be established, usually a PL
level unicast mechanism should first be established in the ForCES
network element. This means a ForCES message should be able to be
delivered in a unicast way between CE and FEs before we setup a
multicast path.
[RFC3654] Khosravi, et al., Requirements for Separation of IP b. The CE PL (or its application layer) forms a PL level multicast
list as defined in 2) of Section 4.2. Note that, because it
represents multicast of a CE to FEs, the multicast list shall include
a multicast id, the CE id, and a number of member FE ids.
c. The multicast list should be sent to the CE TML by TML
configuration service primitive as described by this document. When
CE TML receives this multicast list, the TML is responsible to map
the multicast list to its TML multicast mechanism.
d. The multicast list may also need to be sent to all FE members of
the multicast by use of ForCES protocol configure messages in order
for the FEs to know they belong to this multicast group. Note that a
multicast list has been defined in FE as an attribute of the FE
Protocol LFB [ForCES-PL]. The FEs further send the PL multicast list
to their FE TMLs by means of TML configuration primitive. When the
FEs TMLs receive this multicast list, each TML is responsible to map
the multicast list to its TML multicast mechanism.
e. When a CE PL generates a message with the multicast id as its
destination id and sends it to CE TML, the CE TML will use its TML
level multicast mechanism to distribute the messages to individual
FEs in the multicast group.
f. At the FEs side, when a CE PL message with the multicast id
arrives at the FEs TMLs, each TML use its TML multicast mechanism to
accept the message, and further deliver it to the FE PL.
Above steps may vary in some way according to different TML types
with their different mechanism supporting for TML level multicast.
2) TBD
7. Security Considerations
The risk of being DoS attacked by redirect data has already been
addressed by RFC 3654, RFC 3746, the ForCES protocol specification
[ForCES-PL], etc. Prevention of the DoS attack is one of the key
points to secure the ForCES system. This document specified a TML
event notification of alert from redirect DoS attack to specifically
support a ForCES system to prevent such attack.
TML congestion problem is a broader point of view that may affect
performance of a ForCES system greatly. A TML event notification of
TML congestion alert is defined for TML by this document, so that TML
primitives defined by this document is more capable of improvement of
ForCES system performance.
This document does not define any mechanisms for security services
like endpoint authentication of FE and CE, message authentication,
and confidentiality service This document just reaffirms the
requirement for this security service. This is because that this kind
of security requirement are all specific to TML specifications of
different TML media or individual implementations. Each TML
specification shall provide detailed description on how to meet this
requirement.
8. Acknowledgements
The authors would like to thank Joel M. Halpern, Huaiyuan Ma, et al
for their invaluable comments during evolution of the document.
9. References
[RFC3654] H. Khosravi, et al., Requirements for Separation of IP
Control and Forwarding, RFC 3654, November 2003. Control and Forwarding, RFC 3654, November 2003.
[RFC3746] L. Yang, et al., Forwarding and Control Element Separation
(ForCES) Framework, RFC 3746, April 2004.
[ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft- [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft-
ietf-forces-protocol-08.txt, work-in-progress, Mar. 2006. ietf-forces-protocol-08.txt, work-in-progress, Mar. 2006.
[ForCES-Model] Yang, L., ForCES Forwarding Element Model, Aug. 2003, [ForCES-Model] J. Halpern, E. Deleganes, ForCES Forwarding Element
http://www.ietf.org/internet-drafts/draft-ietf-forces-model-05.txt. Model, draft-ietf-forces-model-06.txt. work-in-progress, Oct. 2006.
8. Author's Address 10. Author's Address
Weiming Wang Weiming Wang
Zhejiang Gongshang University Zhejiang Gongshang University
149 Jiaogong Road 149 Jiaogong Road
Hangzhou 310035 Hangzhou 310035
Hadi Salim Expires Oct., 2006 [Page 17]
P.R.China P.R.China
Phone: +86-571-88071024 Phone: +86-571-28877721
EMail: wmwang@mail.zjgsu.edu.cn EMail: wmwang@mail.zjgsu.edu.cn
Jamal Hadi Salim Jamal Hadi Salim
Znyx Networks Znyx Networks
195 Stafford Rd. West 195 Stafford Rd. West
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Phone:
Email: hadi@znyx.com Email: hadi@znyx.com
Appendix A. TML Attributes XML file Alex Audu
Garland SoftWorx
(TBD) Garland, Texas
USA
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any Phone:
Intellectual Property Rights or other rights that might be claimed to Email: alex.audu@garlandnetworx.com
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 Copyright Statement
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 Copyright (C) The IETF Trust (2007).
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 is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Hadi Salim Expires Oct., 2006 [Page 18]
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 Oct., 2006 [Page 19]
 End of changes. 149 change blocks. 
594 lines changed or deleted 893 lines changed or added

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