idnits 2.17.1
draft-hadi-forces-tmlsp-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 16.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 898.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 875.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 882.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 888.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== There are 3 instances of lines with non-ascii characters in the document.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
(A line matching the expected section header was found, but with an
unexpected indentation:
' 2. Security' )
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 6 instances of too long lines in the document, the longest one
being 1 character in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- Couldn't find a document date in the document -- date freshness check
skipped.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC2119' is mentioned on line 55, but not defined
== Outdated reference: A later version (-22) exists of
draft-ietf-forces-protocol-06
-- Possible downref: Non-RFC (?) normative reference: ref. 'ForCES-Model'
Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 ForCES Working Group W. M. Wang
2 Internet-Draft Zhejiang Gongshang Univ.
3 Expires: Augest, 2006 J. Hadi Salim
4 Znyx Networks
5 Feb. 2006
7 ForCES Transport Mapping Layer (TML) Service Primitives
9 draft-hadi-forces-tmlsp-00.txt
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six
23 months and may be updated, replaced, or obsoleted by other documents
24 at any time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 Copyright Notice
35 Copyright (C) The Internet Society (2006).
37 Conventions used in this document
39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
41 document are to be interpreted as described in [RFC2119].
43 Abstract
45 This document proposes Service Primitives of Transport Mapping Layer
46 (TML) in a Forwarding and Control Element Separation(ForCES) network
47 element, to standardize the operations of ForCES Protocol Layer (PL)
48 to various types of TMLs.
50 Conventions used in this document
52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
54 document are to be interpreted as described in [RFC2119].
56 Table of Contents
58 1. Introduction....................................................2
59 2. Definitions.....................................................3
60 3. Overview........................................................3
61 3.1. ForCES Protocol Framework..................................3
62 3.2. TML Requirements...........................................4
63 4. TML Modeling....................................................5
64 4.1. TML events.................................................6
65 4.2. TML attributes.............................................9
66 4.3. TML capabilities..........................................13
67 5. Service Primitives.............................................13
68 5.1. Design Principles.........................................13
69 5.2. Objectives................................................13
70 5.3. TML Open..................................................14
71 5.4. TML close.................................................14
72 5.5. TML Configuration.........................................15
73 5.6. TML Query.................................................15
74 5.7. TML send..................................................16
75 5.8. TML receive...............................................17
76 6. Theory of Operation............................................17
77 7. References.....................................................17
78 8. Author's Address...............................................17
79 Appendix A. TML Attributes XML file...............................18
81 1. Introduction
83 The Forwarding and Control Element Separation (ForCES) is a proposed
84 architecture for network elements like routers, documents of which
85 include RFC3654, RFC3746, and the ForCES protocol[ForCES-PL] and the
86 ForCES FE model[ForCES-Model] that are working in progress. RFC3654
87 defines the ForCES requirements, RFC3746 defines the ForCES framework,
88 and the ForCES protocol defines the message exchanging protocol
89 between the Forwarding Element (FE) and the Control Element (CE) in
90 the ForCES NE.
92 The ForCES protocol infrastructure constitutes of two components:
94 Hadi Salim Expires Augest, 2006 [Page 2]
95 1. The Protocol Layer (PL), which is responsible for generating
96 ForCES protocol messages and also processing protocol messages that
97 come from peering protocol layers in the same ForCES NE.
99 2. The Transport Mapping Layer (TML), which is responsible for
100 ForCES protocol message transports over variant transport media like
101 IP, Ethernet, ATM, etc.
103 The ForCES protocol, which mainly define the PL, is being worked to
104 be standardized by IETF. TMLs according to various transport media
105 are also to be individually standardized by IETF. A ForCES PL
106 implementation must be portable across all TMLs. It makes feasible
107 that the implementers of TML and PL maybe from different
108 organizations. As a result, there must be a standard method to
109 interconnect PL and TML. A private method would make the PL and TML
110 implementations also private.
112 The purpose of this document is to present the method that
113 standardize the interconnection of PL and variant TMLs. Although
114 there might be other choices like using PL-TML messages, as a more
115 efficient way for data transmission and processing, a method based on
116 service primitives are recommended for interconnection of PL and TML.
117 In this document, a set of TML Service Primitives are presented and
118 related TML parameters are defined. Also presented in the document is
119 the theory of operation of PL-TML based on the service primitives and
120 the parameters.
122 2. Definitions
124 This document follows the terminology used by the ForCES
125 protocol[ForCES-PL]. Some are just copied here:
127 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
128 architecture that defines the ForCES protocol messages, the protocol
129 state transfer scheme, as well as the ForCES protocol architecture
130 itself (including requirements of ForCES TML (see below).
131 Specifications of ForCES PL are defined by [ForCES-PL].
133 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
134 ForCES protocol architecture that uses the capabilities of existing
135 transport protocols to specifically address protocol message
136 transportation issues, such as how the protocol messages are mapped
137 to different transport media (like TCP, IP, ATM, Ethernet, etc), and
138 how to achieve and implement reliability, multicast, ordering, etc.
139 The ForCES TML specifications are detailed in separate ForCES
140 documents, one for each TML.
142 3. Overview
144 3.1. ForCES Protocol Framework
146 Hadi Salim Expires Augest, 2006 [Page 3]
147 The ForCES protocol has presented the protocol framework as in
148 Figure 1. The framework shows the relationship between PL and TML.
149 According to this framework, TML lies under PL and provides services
150 to the PL. CE PL communicates with FE PL via CE TML and FE TML. On
151 transmit, the PL delivers its ForCES messages to the TML. The TML
152 further delivers the message to the destination TML(s). On receive,
153 the TML delivers the ForCES messages it received to the PL.
155 +-----------------------------------------------
156 | CE PL layer |
157 +-----------------------------------------------
158 | CE TML layer |
159 +-----------------------------------------------
160 ^
161 |
162 ForCES |
163 protocol |
164 messages |
165 |
166 |
167 |
168 v
169 +-----------------------------------------------
170 | FE TML layer |
171 +-----------------------------------------------
172 | FE PL layer |
173 +-----------------------------------------------
175 Figure 1
177 3.2. TML Requirements
179 The ForCES protocol [ForCES-PL] also presents TML requirements. We
180 list the requirements as below. These requirements are expected to be
181 delivered by TML using any kind of transport media, though the text
182 does not define how such mechanisms are delivered. Each TML must
183 describe how it contributes to achieving the requirements. If for any
184 reason a TML does not provide a service listed below a justification
185 needs to be provided.
187 The TML requirements are:
189 1. Reliability
190 As defined by RFC 3654, section 6 #6.
192 2. Security
194 Hadi Salim Expires Augest, 2006 [Page 4]
195 TML provides security services to the ForCES PL. TML layer should
196 support the following security services and describe how they are
197 achieved.
199 * Endpoint authentication of FE and CE.
201 * Message Authentication
203 * Confidentiality service
205 3. Congestion Control
206 The congestion control scheme used needs to be defined. The
207 congestion control mechanism defined by the TML should prevent the FE
208 from being overloaded by the CE or the CE from being overwhelmed by
209 traffic from the FE. Additionally, the circumstances under which
210 notification is sent to the PL to notify it of congestion must be
211 defined.
213 4.Uni/multi/broadcast addressing/delivery if any
214 If there is any mapping between PL and TML level Uni/Multi/Broadcast
215 addressing it needs to be defined.
217 5. HA decisions
218 It is expected that availability of transport links is the TML's
219 responsibility. However, on config basis, the PL layer may wish to
220 participate in link failover schemes and therefore the TML must
221 support this capability.
223 6. Encapsulations used.
224 Different types of TMLs will encapsulate the PL messages on
225 different types of headers. The TML needs to specify the
226 encapsulation used.
228 7. Prioritization
229 It is expected that the TML will be able to handle up to 8 priority
230 levels needed by the PL layer and will provide preferential treatment.
231 TML needs to define how this is achieved. The requirement for
232 supporting up to 8 priority levels does not mean that the underlying
233 TML MUST be capable of handling up to 8 priority levels. In such an
234 event the priority levels should be divided between the available TML
235 priority levels. For example, if the TML only supports 2 priority
236 levels, the 0-3 could go in one TML priority level, while 4-7 could
237 go in the other.
239 8. Protection against DoS attacks
240 As described in the Requirements RFC 3654, section 6
242 4. TML Modeling
244 Hadi Salim Expires Augest, 2006 [Page 5]
245 To make PL capable of interconnection with variant TMLs in a
246 standardized way, the first work to do is to model the variant TMLs
247 in a uniform way from the perspective of a uniform PL.
249 Identical to modeling an LFB in an FE, from the perspective of PL,
250 TML properties can be abstracted by the following entities:
252 TML Events:
253 The TML events that PL requires to know when the events happen in
254 the TML.
256 TML attributes:
257 The TML attributes that are required to be configured by PL
258 according to PL requirements. The attributes can also be queried by
259 PL.
261 TML capabilities:
262 The TML capabilities that PL are interested to know.
264 Note that, not all TML properties should be made perceivable by PL
265 from PL point of view. PL only cares those TML properties that are
266 common to all TMLs and that PL should interact with via service
267 primitives so that TML can work according to PL's requirements.
269 Via TML Service Primitives, PL should be able to access above
270 properties of variant TMLs.
272 4.1.TML events
274 There might be several TML events, but only some of them are PL must
275 sense via PL-TML interface.
277 A callback mechanism is defined for PL to sense the TML events by
278 PL-TML service primitives. PL first provides every event with a
279 callback function for the event processing in the PL. PL then tells
280 the callback handle to TML by service primitives. The callback handle
281 is usually stored in TML as a parameter. Whenever the relavent event
282 happens in TML, the TML triggers the handle to notify PL of the event.
283 PL executes the callback function, and asynchronously begins to
284 process the event.
286 After a TML event happened and PL is notified and a procedure to
287 process the event is executed, PL may be further interested in
288 knowing if the event status in the TML still exists or not. To meet
289 this requirement, an 'eventState' parameter is used in callback
290 functions to indicate if the reported is the event happened or the
291 event released. Whereas, not all events need to notify PL of their
292 release state.
294 Hadi Salim Expires Augest, 2006 [Page 6]
295 The following TML events must be made to be notified by PL. If for
296 any reason a TML does not provide the service, a justification needs
297 to be provided in the TML specification.
299 1) TML failure event
301 This event happens when there is a TML failure. It is up to
302 individual TML specifications and even individual implementations to
303 specify the detailed event triggering conditions, but usually, TML
304 failure should include the following cases:
305 . local TML link failure
306 . peer TML unavailable
307 . peer TML left
309 The different cases that cause the failure will be stated by a
310 failure code in the event callback function.
312 Callback handle for TML failure event is then defined as:
314 status = -- SUCCESS or errorIndication
315 callbackTMLFailureEvent(
316 IN eventState
317 IN failCode
318 )
319 Where,
320 eventState = EventHAPPENED or EventRELEASED
321 failCode indicates the failure case
323 2) Message arrival event
325 TML can make it as an event when a PL ForCES protocol message coming
326 from peering TML arrives at the TML and the TML has made it ready for
327 PL to receive the message. In this way, an asynchronous message
328 receive mode can be realized in PL. In addition to this asynchronous
329 mode, PL can also use a specific TML receive service primitive
330 (defined below) for synchronous reception of PL messages.
332 Callback handle for message arrival event is defined as:
334 status = -- SUCCESS or errorIndication
335 callbackTMLMsgArrivalEvent(
336 IN msglen
337 IN msgPDU
338 )
339 Where, msglen indicates the ForCES message length, and msgPDU is the
340 ForCES message body in its Protocol Data Unit format. There is no
341 need for message arrival event to notify a release state.
343 3) Control message congestion event
345 Hadi Salim Expires Augest, 2006 [Page 7]
346 ForCES control messages are defined as all ForCES protocol messages
347 except ForCES redirect messages. ForCES redirect messages are
348 identified by the ForCES message types being marked as
349 'PacketRedirect'.
351 This event happens when the TML comes to a congestion state for the
352 control message transmission. It is up to individual TML
353 specifications and even individual implementations to specify the
354 detailed event triggering conditions.
356 This event can be used by PL layer to monitor the control message
357 transmission. In FEs, this event may also be used to help monitoring
358 possible DoS attacks from redirected packets.
360 Callback handle for TML control message congestion event is defined
361 as:
363 status = -- SUCCESS or errorIndication
364 callbackTMLCtrMsgCongestEvent(
365 IN eventState
366 )
367 Where,
368 eventState = EventHAPPENED or EventRELEASED
370 4)Redirect message congestion event
372 This event happens when the TML comes to a congestion state for the
373 PL redirect message transmission. It is up to individual TML
374 specifications and even individual implementations to specify the
375 detailed event triggering conditions.
377 This event can be used by PL layer to monitor the redirect message
378 transmission. In FEs, this may also be used to help monitoring
379 possible DoS attacks from redirect packets.
381 Callback handle for TML redirect message congestion event is defined
382 as:
384 status = -- SUCCESS or errorIndication
385 callbackTMLRedMsgCongestEvent(
386 IN eventState
387 )
388 Where,
389 eventState = EventHAPPENED or EventRELEASED
391 5)DoS attack alert event
393 This event happens when the TML comes to a state that it feels there
394 are abnormal amount of PL redirect messages and there has made it
395 quite hard to transport PL control messages. Whereas, it is up to
397 Hadi Salim Expires Augest, 2006 [Page 8]
398 individual TML specifications and even individual implementations to
399 specify the detailed and precise triggering conditions for the event.
401 This event is used by PL to monitor the security state for TML
402 message transmission. In FEs, when this event happens, usually FE PL
403 should trigger a DoS attack alert event to inform CE of the event. CE
404 may take further effects trying to prevent the attack. Note that, the
405 event is an alert, when it happens, usually it does not mean the CE-
406 FE communication is totally lost.
408 Callback handle for TML DoS attack alert event is defined as:
410 status = -- SUCCESS or errorIndication
411 callbackTMLDoSAttackAlertEvent(
412 IN eventState
413 )
414 Where,
415 eventState = EventHAPPENED or EventRELEASED
417 4.2.TML attributes
419 1) Event handles
421 Event handles are handles for PL to access events. An event callback
422 function handle is used as the purpose. Defining the handles as an
423 attribute of the TML, then, for PL to set the handle to TML is for
424 the PL to subscribe to the TML for the event notification, to delete
425 the handle from the TML is to unsubscribe the event from the TML.
427 We define the event handle TML attribute as below:
429
430 Eventhandle
431 Event callback handle
432
433
434 eventType
435 event type represented by an ID
436 uint16
437
438 TMLFailureEvent
440 TML failure event
441
442 TMLMsgArrivalEvent
444 TML ForCES message arrival event
445
446 TMLCtrMsgCongestEvent
449 Hadi Salim Expires Augest, 2006 [Page 9]
450
451 TML ForCES congtrol message transmit congestion event
452
453
454 TMLRedMsgCongestEvent
456
457 TML ForCES redirect message transmit congestion event
458
459
460 TMLDoSAttackAlertEvent
462 TML DoS attack alert event
463
464
465
466
467 handle
468 callback function handle of the event
469 uint64
470
471
472
474 EventHandles
476 event handle table in the TML
477
478 EventHandle
479
480
482 2)multicast lists
484 This attribute is used for TML to multicast ForCES messages. The
485 multicast list should be configured by PL, but individual TML
486 specifications should define how such multicast list maps to TML
487 transport level multicast mechanisms.
489 A PL level multicast list includes a group ID for the multicast and
490 a number of members of the multicast. The members are represented by
491 PL level protocol src/destIDs (include FE ID and CE ID).
493 Note that, there might be more than one multicast group for
494 multicast applications. The multiple multicast lists form a multicast
495 list table in TML.
497 The attribute for the multicast lists is defined as below:
498 }
499
500 McastList
501
502 a PL level multicast list for ForCES multicast transport
503
504
505
506 groupID
507 32bits group ID of the multicast
508 uint32
509
510
511 members
512
513 members of the multicast represented by FE ID or CE ID
514
515
516 uint32
517
518
519
520
522 McastLists
524
525 a table representing several multicast lists in the TML
526
527
528 McastList
529
530
532 3) Working TML Type
534 A TML implementation may be capable of several TML transport ways.
535 For example, a TML with IP transport media may be able to support
536 several transport protocols, like TCP+UDP, TCP+DCCP, SCTP, etc. In
537 this case, there should be a TML attribute describing the different
538 types and make PL able to switch among the types under the control of
539 CE.
541 The TML type is represented by an ID, defined as below:
543
544 TMLType
545 TML Type
546
547 uint16
548
549 TmlTcpUdp
551 TML uses TCP+UDP
552
553 TmlTcpDccp
555 TML uses TCP+DCCP
556
557 TmlSctp
559 TML uses SCTP
560
561 TmlEth
563 TML uses Ethernet
564
565 TmlAtm
567 TML uses ATM
568
569
570
571
573 The TML attribute for the working TML type is defined as below:
575 WorkingTMLType
577 current working TML type assigned by PL
578 TMLType
579
581 Note that, the working TML type attribute may be configurable or may
582 only be readable depending on implementations. TML capability on the
583 TML type (defined below) will tell if it is configurable or not. To
584 query the TML type capability before configuring the working TML type
585 attribute will help to correctly configure it.
587 4) Media specific TML parameters
589 Individual TML may require configuring some TML parameters specific
590 to its TML media. There leave a space in TML service primitives for
591 such requirement. Individual TML specifications should provide
592 detailed definitions for such parameters.
594 5) Vendor specific TML parameters
596 Vendors of individual implementations of TML may require configuring
597 some TML parameters specific to its implementation. There leave a
598 space in TML service primitives for such requirement. Individual
599 implementation should provide detailed definitions for such
600 parameters.
602 4.3. TML capabilities
604 1) Supported TML type
606 A TML implementation may be capable of several TML transport ways.
607 This capability indicates PL of the supported types.
609 The TML capability for the supported TML type is defined as below:
611 SupportedTMLType
613 supported TML types in the TML mechanism
614 TMLType
616
617
619 2) TML type configuration capability
621 TMLTypeConfigurable
623 TML Type configurable or not by PL
624 boolean
625
627 5. Service Primitives
629 5.1.Design Principles
631 Two principles are applied to this PL-TML service primitives design:
633 1.PL-TML service primitives should hide implementation details
634 regarding reliability, security, multicast, congestion control, etc
635 from PL.
637 2.PL-TML service primitives should avoid leading TML to read ForCES
638 protocol message PDU to get information, so as to immunize the TML
639 from the possible change of ForCES protocol PDU (like the protocol
640 update).
642 5.2.Objectives
644 There are several basic design objectives:
646 1. Support for unicast, multicast and broadcast PL level mechanisms.
647 2. support for both reliable and unreliable delivery.
648 3. Support for in-order or agnostic delivery.
650 4. Support for timeliness requirements.
651 5. Support for both synchronous and asynchronous operations.
652 6. Support for event notifications from TML to PL.
654 5.3. TML Open
656 Syntax:
657 status = -- SUCCESS or errorIndication
658 TMLopen( )
660 Parameters:
661 none
663 Service Description:
664 The PL connects to the TML by invoking the TML open call. It highly
665 depends on the individual TML specifications what a TML should do
666 after receiving this call. For some TMLs, this primitive call may
667 only act as a signal to inform TML that PL is going to use the TML
668 for sending or receiving PL messages, while for some other TMLs, a
669 TML may have to do some TML level operation to prepare for PL usage
670 when receiving this primitive call. For example, For a connectionless
671 TML, this open primitive may does not have to do anything, while for
672 a connection-oriented TML, this open call may be a signal for the TML
673 to setup TML level connection(s) to peering TML(this actually means
674 the peer-to-peer TMLs do not have to always be connected after the
675 TML is initialized and during the post-association phase).
677 Another important point is, to better synchronize the operations
678 between peering PLs, the TML will have to discard all the PL messages
679 received from peering PL before the local TML has not yet been opened
680 by the local PL,
682 5.4. TML close
684 Syntax:
685 status = -- SUCCESS or errorIndication
686 TMLclose( )
688 Parameters:
689 none
691 Service Description:
692 In this call, the PL disconnects from the TML. It highly depends on
693 the individual TML specifications what a TML should do after
694 receiving this call. For some TMLs, this primitive call may only act
695 as a signal to inform TML that PL is not going to use the TML for
696 sending or receiving PL messages anymore, while for some other TMLs,
697 a TML may have to do some extra TML level operations to disconnect it
698 to peering TMLs. For example, for a connectionless TML, this
699 primitive may do not have to do anything, while for a connection-
700 oriented TML, this primitive call may be a signal for the TML to
701 disconnect all TML level connections to peering TML.
703 Another important point is, to better synchronize the operations
704 between peering PLs, a TML will have to discard all PL messages
705 received by the TML after the TML has been closed by local PL.
707 5.5.TML Configuration
709 Syntax:
710 status = -- SUCCESS or errorIndication
711 TMLconfig(
712 IN operation
713 IN path
714 IN data
715 )
716 Parameters:
718 operation ?the operation type for the configuration. Two operations
719 are defined:
720 operation = ADD ?to add parameter
721 = DELETE ?to delete parameter
723 path ?a path composed of element ID(s) and (or) array index
724 pointing to the element to be configured.
725 (TBD)
727 data ?the data to be configured to the element.
728 (TBD)
730 Service Description:
731 This primitive is used by the PL to control the behavior of the TML
732 by the PL layer configuring the related property elements in the TML.
733 The element is indicated by the 'path'. The value to be configured to
734 the element is accessed by the 'data'.
736 5.6. TML Query
738 Syntax:
739 status = -- SUCCESS or errorIndication
740 TMLquery(
741 IN path
742 OUT data
743 )
744 Parameters:
746 path ?a path composed of element ID(s) and (or) array index
747 pointing to the element to be queried.
748 (TBD)
749 data ?the data returned by the query.
750 (TBD)
752 Service Description:
754 This primitive is used by the PL to query the behavior of the TML.
755 The querying element is indicated by the 'path'. The value queried is
756 stored at the 'data' field. The TML executes the primitive by filling
757 out the data field with the queried value of the element.
759 5.7. TML send
761 Syntax:
762 status = -- SUCCESS or errorIndication
763 TMLsend(
764 IN msgDestID,
765 IN msgType,
766 IN msgPrio,
767 IN msgLength,
768 IN msgPDU,
769 )
771 Parameters:
772 msgDestID: the destination ID for the PL message to be sent
773 msgType: the message type for the PL message to be sent
774 msgPrio: the message priority for the PL message to be sent
775 msgLen: the message length to be sent
776 msgPDU: the ForCES protocol message to be sent in its PDU
778 Service Description:
779 In this service, the PL sends a message to one (unicast) or more
780 (multicast) peer PLs via the TML. Note that this primitive includes
781 all parameters that are necessary for TML to manage transmission of
782 the PL message, therefore, there is no need for the TML to read in
783 the PL message body to retrieve this parameters. In this way, we may
784 decouple changes in ForCES protocol PDU (e.g., by the protocol update)
785 from TML level.
787 The msgDestID is used for the TML to find out TML layer transport
788 addresses for the message transmission. It also includes the
789 processing for PL message multicast transports, for the destination
790 ID may also be a multicast group ID.
792 The msgType is used for the TML to infer the requirements from PL
793 level for the manage sending, regarding its reliability, timeliness,
794 security, and congestion control. With this message type, it is easy
795 to recognize PL redirect messages from PL control messages.
797 Individual TML specifications should define how the msgTypes are used
798 to map into the TML requirements.
800 The msgPrio is used for the TML to meet the PL requirement for the
801 message transmission priority; it may also be used for TML to meet
802 the TML requirements for reliability, timeliness, security, and
803 congestion control. Individual TML specifications should define how
804 the priority is mapped into the TML transport mechanisms for
805 prioritized transmission. Individual TML specifications may also
806 define how the priority is used for other TML requirements.
808 5.8. TML receive
810 Syntax:
811 status = -- SUCCESS or errorIndication
812 TMLreceive(
813 IN msgLength,
814 IN msgPDU,
815 )
817 Parameters:
818 msgLen: the length of the message received.
819 msgPDU: the received ForCES protocol message body in its PDU
820 format
822 Service Description:
823 This service is used for PL to synchronously receive PL messages
824 from peering TML.
826 Note that a PL message arrival event described before can also be
827 used for PL to receive PL messages from TML. The difference is that
828 this TML receive primitive makes PL to synchronously receive messages,
829 while a PL message arrival event receives messages in an asynchronous
830 way. Usually, an asynchronous method is more efficient in terms of
831 CPU cycles.
833 6. Theory of Operation
835 (TBD)
837 7. References
839 [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft-
840 ietf-forces-protocol-06.txt, work-in-progress, Dec. 2005.
842 [ForCES-Model] Yang, L., "ForCES Forwarding Element Model", Aug.
843 2003, http://www.ietf.org/internet-drafts/draft-ietf-forces-model-
844 05.txt.
846 8. Author's Address
847 Weiming Wang
848 Zhejiang Gongshang University
849 149 Jiaogong Road
850 Hangzhou 310035
851 P.R.China
852 Phone: +86-571-88071024
853 EMail: wmwang@mail.zjgsu.edu.cn
855 Jamal Hadi Salim
856 Znyx Networks
857 195 Stafford Rd. West
858 Ottawa, Ontario
859 Canada
860 Email: hadi@znyx.com
862 Appendix A. TML Attributes XML file
864 (TBD)
866 Intellectual Property Statement
868 The IETF takes no position regarding the validity or scope of any
869 Intellectual Property Rights or other rights that might be claimed to
870 pertain to the implementation or use of the technology described in
871 this document or the extent to which any license under such rights
872 might or might not be available; nor does it represent that it has
873 made any independent effort to identify any such rights. Information
874 on the procedures with respect to rights in RFC documents can be
875 found in BCP 78 and BCP 79.
877 Copies of IPR disclosures made to the IETF Secretariat and any
878 assurances of licenses to be made available, or the result of an
879 attempt made to obtain a general license or permission for the use of
880 such proprietary rights by implementers or users of this
881 specification can be obtained from the IETF on-line IPR repository at
882 http://www.ietf.org/ipr.
884 The IETF invites any interested party to bring to its attention any
885 copyrights, patents or patent applications, or other proprietary
886 rights that may cover technology that may be required to implement
887 this standard. Please address the information to the IETF at ietf-
888 ipr@ietf.org.
890 Disclaimer of Validity
892 This document and the information contained herein are provided on
893 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
894 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
895 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
896 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
897 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
898 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
900 Copyright Statement
902 Copyright (C) The Internet Society (2006). This document is subject
903 to the rights, licenses and restrictions contained in BCP 78, and
904 except as set forth therein, the authors retain all their rights.
906 Acknowledgment
908 Funding for the RFC Editor function is currently provided by the
909 Internet Society.