idnits 2.17.1
draft-ietf-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 909.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 886.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 893.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 899.
** 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:
----------------------------------------------------------------------------
== 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.)
-- The document date (April 2006) is 6585 days in the past. Is this
intentional?
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 42, but not defined
== Unused Reference: 'RFC3654' is defined on line 845, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational RFC: RFC 3654
== Outdated reference: A later version (-22) exists of
draft-ietf-forces-protocol-08
-- Possible downref: Non-RFC (?) normative reference: ref. 'ForCES-Model'
Summary: 8 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: October, 2006 J. Hadi Salim
4 Znyx Networks
5 April 2006
7 ForCES Transport Mapping Layer (TML) Service Primitives
9 draft-ietf-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 a variety of TMLs.
50 Table of Contents
52 1. Introduction....................................................2
53 2. Definitions.....................................................3
54 3. Overview........................................................3
55 3.1. ForCES Protocol Framework..................................3
56 3.2. TML Requirements...........................................4
57 4. TML Modeling....................................................5
58 4.1. TML events.................................................6
59 4.2. TML attributes.............................................9
60 4.3. TML capabilities..........................................12
61 5. Service Primitives.............................................13
62 5.1. Design Principles.........................................13
63 5.2. Objectives................................................13
64 5.3. TML Open..................................................13
65 5.4. TML close.................................................14
66 5.5. TML Configuration.........................................15
67 5.6. TML Query.................................................15
68 5.7. TML send..................................................16
69 5.8. TML receive...............................................17
70 6. Theory of Operation............................................17
71 7. References.....................................................17
72 8. Author's Address...............................................17
73 Appendix A. TML Attributes XML file...............................18
75 1. Introduction
77 The Forwarding and Control Element Separation (ForCES) is a proposed
78 architecture for network elements like routers, documents of which
79 include RFC3654, RFC3746, and the ForCES protocol[ForCES-PL] and the
80 ForCES FE model[ForCES-Model] that are work in progress. RFC3654
81 defines the ForCES requirements, RFC3746 defines the ForCES framework,
82 and the ForCES protocol defines the message exchange protocol between
83 the Forwarding Element (FE) and the Control Element (CE) in the
84 ForCES NE (see RFC3654 for the terminology definitions).
86 The ForCES protocol infrastructure consists of two components:
88 1. The Protocol Layer (PL), which is responsible for generating
89 ForCES protocol messages and also processing protocol messages that
90 come from peering protocol layers in the same ForCES NE.
92 Hadi Salim Expires Oct., 2006 [Page 2]
93 2. The Transport Mapping Layer (TML), which is responsible for
94 ForCES protocol message transports over variant transport media like
95 IP, Ethernet, ATM, etc.
97 The IETF ForCES protocol mainly defines the PL. TMLs according to
98 various transport media are also to be individually defined by IETF.
99 A ForCES PL implementation must be portable across all TMLs. It is
100 feasible that the implementers of TML and PL may be from different
101 organizations. As a result, there must be an interoperable method to
102 interconnect the PL and TML. A private method would make the PL and
103 TML implementations also private.
105 The purpose of this document is to present the method for an
106 interoperable interconnection of the PL and a variety of TMLs.
107 Although there might be other choices like using PL-TML messages, as
108 a more efficient way for data transmission and processing, a method
109 based on service primitives are recommended for interconnection of PL
110 and TML. In this document, a set of TML Service Primitives are
111 presented and related TML parameters are defined. Also presented in
112 the document is the theory of operation of PL-TML based on the
113 service primitives and the parameters.
115 2. Definitions
117 This document follows the terminology used by RFC3654, RFC3746, and
118 the ForCES protocol[ForCES-PL]. Some are just copied here:
120 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
121 architecture that defines the ForCES protocol messages, the protocol
122 state transfer scheme, as well as the ForCES protocol architecture
123 itself (including requirements of ForCES TML (see below).
124 Specifications of ForCES PL are defined by [ForCES-PL].
126 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
127 ForCES protocol architecture that uses the capabilities of existing
128 transport protocols to specifically address protocol message
129 transportation issues, such as how the protocol messages are mapped
130 to different transport media (like TCP, IP, ATM, Ethernet, etc), and
131 how to achieve and implement reliability, multicast, ordering, etc.
132 The ForCES TML specifications are detailed in separate ForCES
133 documents, one for each TML.
135 3. Overview
137 3.1. ForCES Protocol Framework
139 The ForCES protocol has presented the protocol framework as in
140 Figure 1. The framework shows the relationship between PL and TML.
141 According to this framework, TML lies under PL and provides services
142 to the PL. CE PL communicates with FE PL via CE TML and FE TML. On
144 Hadi Salim Expires Oct., 2006 [Page 3]
145 transmit, the PL delivers its ForCES messages to the TML. The TML
146 further delivers the message to the destination TML(s). On receive,
147 the TML delivers the ForCES messages it received to the PL.
149 +-----------------------------------------------
150 | CE PL layer |
151 +-----------------------------------------------
152 | CE TML layer |
153 +-----------------------------------------------
154 ^
155 |
156 ForCES |
157 protocol |
158 messages |
159 |
160 |
161 |
162 v
163 +-----------------------------------------------
164 | FE TML layer |
165 +-----------------------------------------------
166 | FE PL layer |
167 +-----------------------------------------------
169 Figure 1
171 3.2. TML Requirements
173 The ForCES protocol [ForCES-PL] also presents TML requirements. We
174 list the requirements as below. These requirements are expected to be
175 delivered by TML using any kind of transport media, though the text
176 does not define how such mechanisms are delivered. Each TML must
177 describe how it contributes to achieving the requirements. If for any
178 reason a TML does not provide a service listed below a justification
179 needs to be provided.
181 The TML requirements are:
183 1. Reliability
184 As defined by RFC 3654, section 6 #6.
186 2. Security
187 TML provides security services to the ForCES PL. TML layer should
188 support the following security services and describe how they are
189 achieved.
191 * Endpoint authentication of FE and CE.
193 * Message Authentication
195 Hadi Salim Expires Oct., 2006 [Page 4]
196 * Confidentiality service
198 3. Congestion Control
199 The congestion control scheme used needs to be defined. The
200 congestion control mechanism defined by the TML should prevent the FE
201 from being overloaded by the CE or the CE from being overwhelmed by
202 traffic from the FE. Additionally, the circumstances under which
203 notification is sent to the PL to notify it of congestion must be
204 defined.
206 4.Uni/multi/broadcast addressing/delivery if any
207 If there is any mapping between PL and TML level Uni/Multi/Broadcast
208 addressing it needs to be defined.
210 5. HA decisions
211 It is expected that availability of transport links is the TML's
212 responsibility. However, on config basis, the PL layer may wish to
213 participate in link failover schemes and therefore the TML must
214 support this capability.
216 6. Encapsulations used.
217 Different types of TMLs will encapsulate the PL messages on
218 different types of headers. The TML needs to specify the
219 encapsulation used.
221 7. Prioritization
222 It is expected that the TML will be able to handle up to 8 priority
223 levels needed by the PL layer and will provide preferential treatment.
224 TML needs to define how this is achieved. The requirement for
225 supporting up to 8 priority levels does not mean that the underlying
226 TML MUST be capable of handling up to 8 priority levels. In such an
227 event the priority levels should be divided between the available TML
228 priority levels. For example, if the TML only supports 2 priority
229 levels, the 0-3 could go in one TML priority level, while 4-7 could
230 go in the other.
232 8. Protection against DoS attacks
233 As described in the Requirements RFC 3654, section 6
235 4. TML Modeling
237 To make PL capable of interconnection with variant TMLs in a
238 standardized way, the first work to do is to model the variant TMLs
239 in a uniform way from the perspective of a uniform PL.
241 Identical to modeling an LFB in an FE, from the perspective of PL,
242 TML properties can be abstracted by the following entities:
244 TML Events:
246 Hadi Salim Expires Oct., 2006 [Page 5]
247 The TML events that PL requires to know when the events happen in
248 the TML.
250 TML attributes:
251 The TML attributes that are required to be configured by PL
252 according to PL requirements. The attributes can also be queried by
253 PL.
255 TML capabilities:
256 The TML capabilities that PL are interested to know.
258 Note that, not all TML properties should be made perceivable by PL
259 from PL point of view. PL only cares those TML properties that are
260 common to all TMLs and that PL should interact with via service
261 primitives so that TML can work according to PL's requirements.
263 Via TML Service Primitives, PL should be able to access above
264 properties of variant TMLs.
266 4.1.TML events
268 There might be several TML events, but only some of them are PL must
269 sense via PL-TML interface.
271 A callback mechanism is defined for PL to sense the TML events by
272 PL-TML service primitives. PL first provides every event with a
273 callback function for the event processing in the PL. PL then tells
274 the callback handle to TML by service primitives. The callback handle
275 is usually stored in TML as a parameter. Whenever the relavent event
276 happens in TML, the TML triggers the handle to notify PL of the event.
277 PL executes the callback function, and asynchronously begins to
278 process the event.
280 After a TML event happened and PL is notified and a procedure to
281 process the event is executed, PL may be further interested in
282 knowing if the event status in the TML still exists or not. To meet
283 this requirement, an 'eventState' parameter is used in callback
284 functions to indicate if the reported is the event happened or the
285 event released. Whereas, not all events need to notify PL of their
286 release state.
288 The following TML events must be made to be notified by PL. If for
289 any reason a TML does not provide the service, a justification needs
290 to be provided in the TML specification.
292 1) TML failure event
294 This event happens when there is a TML failure. It is up to
295 individual TML specifications and even individual implementations to
297 Hadi Salim Expires Oct., 2006 [Page 6]
298 specify the detailed event triggering conditions, but usually, TML
299 failure should include the following cases:
300 . local TML link failure
301 . peer TML unavailable
302 . peer TML left
304 The different cases that cause the failure will be stated by a
305 failure code in the event callback function.
307 Callback handle for TML failure event is then defined as:
309 status = -- SUCCESS or errorIndication
310 callbackTMLFailureEvent(
311 IN eventState
312 IN failCode
313 )
314 Where,
315 eventState = EventHAPPENED or EventRELEASED
316 failCode indicates the failure case
318 2) Message arrival event
320 TML can make it as an event when a PL ForCES protocol message coming
321 from peering TML arrives at the TML and the TML has made it ready for
322 PL to receive the message. In this way, an asynchronous message
323 receive mode can be realized in PL. In addition to this asynchronous
324 mode, PL can also use a specific TML receive service primitive
325 (defined below) for synchronous reception of PL messages.
327 Callback handle for message arrival event is defined as:
329 status = -- SUCCESS or errorIndication
330 callbackTMLMsgArrivalEvent(
331 IN msglen
332 IN msgPDU
333 )
334 Where, msglen indicates the ForCES message length, and msgPDU is the
335 ForCES message body in its Protocol Data Unit format. There is no
336 need for message arrival event to notify a release state.
338 3) Control message congestion event
340 ForCES control messages are defined as all ForCES protocol messages
341 except ForCES redirect messages. ForCES redirect messages are
342 identified by the ForCES message types being marked as
343 'PacketRedirect'.
345 This event happens when the TML comes to a congestion state for the
346 control message transmission. It is up to individual TML
348 Hadi Salim Expires Oct., 2006 [Page 7]
349 specifications and even individual implementations to specify the
350 detailed event triggering conditions.
352 This event can be used by PL layer to monitor the control message
353 transmission. In FEs, this event may also be used to help monitoring
354 possible DoS attacks from redirected packets.
356 Callback handle for TML control message congestion event is defined
357 as:
359 status = -- SUCCESS or errorIndication
360 callbackTMLCtrMsgCongestEvent(
361 IN eventState
362 )
363 Where,
364 eventState = EventHAPPENED or EventRELEASED
366 4)Redirect message congestion event
368 This event happens when the TML comes to a congestion state for the
369 PL redirect message transmission. It is up to individual TML
370 specifications and even individual implementations to specify the
371 detailed event triggering conditions.
373 This event can be used by PL layer to monitor the redirect message
374 transmission. In FEs, this may also be used to help monitoring
375 possible DoS attacks from redirect packets.
377 Callback handle for TML redirect message congestion event is defined
378 as:
380 status = -- SUCCESS or errorIndication
381 callbackTMLRedMsgCongestEvent(
382 IN eventState
383 )
384 Where,
385 eventState = EventHAPPENED or EventRELEASED
387 5)DoS attack alert event
389 This event happens when the TML comes to a state that it feels there
390 are abnormal amount of PL redirect messages and there has made it
391 quite hard to transport PL control messages. Whereas, it is up to
392 individual TML specifications and even individual implementations to
393 specify the detailed and precise triggering conditions for the event.
395 This event is used by PL to monitor the security state for TML
396 message transmission. In FEs, when this event happens, usually FE PL
397 should trigger a DoS attack alert event to inform CE of the event. CE
398 may take further effects trying to prevent the attack. Note that, the
400 Hadi Salim Expires Oct., 2006 [Page 8]
401 event is an alert, when it happens, usually it does not mean the CE-
402 FE communication is totally lost.
404 Callback handle for TML DoS attack alert event is defined as:
406 status = -- SUCCESS or errorIndication
407 callbackTMLDoSAttackAlertEvent(
408 IN eventState
409 )
410 Where,
411 eventState = EventHAPPENED or EventRELEASED
413 4.2.TML attributes
415 1) Event handles
417 Event handles are handles for PL to access events. An event callback
418 function handle is used as the purpose. Defining the handles as an
419 attribute of the TML, then, for PL to set the handle to TML is for
420 the PL to subscribe to the TML for the event notification, to delete
421 the handle from the TML is to unsubscribe the event from the TML.
423 We define the event handle TML attribute as below:
425
426 Eventhandle
427 Event callback handle
428
429
430 eventType
431 event type represented by an ID
432 uint16
433
434
435 TMLFailureEvent
436 TML failure event
437
438
439 TMLMsgArrivalEvent
440 TML ForCES message arrival event
441
442
443 TMLCtrMsgCongestEvent
444
445 TML ForCES congtrol message transmit congestion event
446
447
448
449 TMLRedMsgCongestEvent
450
452 Hadi Salim Expires Oct., 2006 [Page 9]
453 TML ForCES redirect message transmit congestion event
454
455
456
457 TMLDoSAttackAlertEvent
458 TML DoS attack alert event
459
460
461
462
463 handle
464 callback function handle of the event
465 uint64
466
467
468
470
471 EventHandles
472 event handle table in the TML
473
474 EventHandle
475
476
478 2)multicast lists
480 This attribute is used for TML to multicast ForCES messages. The
481 multicast list should be configured by PL, but individual TML
482 specifications should define how such multicast list maps to TML
483 transport level multicast mechanisms.
485 A PL level multicast list includes a group ID for the multicast and
486 a number of members of the multicast. The members are represented by
487 PL level protocol src/destIDs (include FE ID and CE ID).
489 Note that, there might be more than one multicast group for
490 multicast applications. The multiple multicast lists form a multicast
491 list table in TML.
493 The attribute for the multicast lists is defined as below:
494 }
495
496 McastList
497
498 a PL level multicast list for ForCES multicast transport
499
500
501
502 groupID
504 Hadi Salim Expires Oct., 2006 [Page 10]
505 32bits group ID of the multicast
506 uint32
507
508
509 members
510
511 members of the multicast represented by FE ID or CE ID
512
513
514 uint32
515
516
517
518
520
521 McastLists
522
523 a table representing several multicast lists in the TML
524
525
526 McastList
527
528
530 3) Working TML Type
532 A TML implementation may be capable of several TML transport ways.
533 For example, a TML with IP transport media may be able to support
534 several transport protocols, like TCP+UDP, TCP+DCCP, SCTP, etc. In
535 this case, there should be a TML attribute describing the different
536 types and make PL able to switch among the types under the control of
537 CE.
539 The TML type is represented by an ID, defined as below:
541
542 TMLType
543 TML Type
544
545 uint16
546
547
548 TmlTcpUdp
549 TML uses TCP+UDP
550
551
552 TmlTcpDccp
553 TML uses TCP+DCCP
555 Hadi Salim Expires Oct., 2006 [Page 11]
556
557
558 TmlSctp
559 TML uses SCTP
560
561
562 TmlEth
563 TML uses Ethernet
564
565
566 TmlAtm
567 TML uses ATM
568
569
570
571
573 The TML attribute for the working TML type is defined as below:
575
576 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 Hadi Salim Expires Oct., 2006 [Page 12]
607 A TML implementation may be capable of several TML transport ways.
608 This capability indicates PL of the supported types.
610 The TML capability for the supported TML type is defined as below:
612
613 SupportedTMLType
614 supported TML types in the TML mechanism
615
616 TMLType
617
618
620 2) TML type configuration capability
622
623 TMLTypeConfigurable
624 TML Type configurable or not by PL
625 boolean
626
628 5. Service Primitives
630 5.1.Design Principles
632 Two principles are applied to this PL-TML service primitives design:
634 1.PL-TML service primitives should hide implementation details
635 regarding reliability, security, multicast, congestion control, etc
636 from PL.
638 2.PL-TML service primitives should avoid leading TML to read ForCES
639 protocol message PDU to get information, so as to immunize the TML
640 from the possible change of ForCES protocol PDU (like the protocol
641 update).
643 5.2.Objectives
645 There are several basic design objectives:
647 1. Support for unicast, multicast and broadcast PL level mechanisms.
648 2. support for both reliable and unreliable delivery.
649 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:
658 Hadi Salim Expires Oct., 2006 [Page 13]
659 status = -- SUCCESS or errorIndication
660 TMLopen( )
662 Parameters:
663 none
665 Service Description:
666 The PL connects to the TML by invoking the TML open call. It highly
667 depends on the individual TML specifications what a TML should do
668 after receiving this call. For some TMLs, this primitive call may
669 only act as a signal to inform TML that PL is going to use the TML
670 for sending or receiving PL messages, while for some other TMLs, a
671 TML may have to do some TML level operation to prepare for PL usage
672 when receiving this primitive call. For example, For a connectionless
673 TML, this open primitive may does not have to do anything, while for
674 a connection-oriented TML, this open call may be a signal for the TML
675 to setup TML level connection(s) to peering TML(this actually means
676 the peer-to-peer TMLs do not have to always be connected after the
677 TML is initialized and during the post-association phase).
679 Another important point is, to better synchronize the operations
680 between peering PLs, the TML will have to discard all the PL messages
681 received from peering PL before the local TML has not yet been opened
682 by the local PL,
684 5.4. TML close
686 Syntax:
687 status = -- SUCCESS or errorIndication
688 TMLclose( )
690 Parameters:
691 none
693 Service Description:
694 In this call, the PL disconnects from the TML. It highly depends on
695 the individual TML specifications what a TML should do after
696 receiving this call. For some TMLs, this primitive call may only act
697 as a signal to inform TML that PL is not going to use the TML for
698 sending or receiving PL messages anymore, while for some other TMLs,
699 a TML may have to do some extra TML level operations to disconnect it
700 to peering TMLs. For example, for a connectionless TML, this
701 primitive may do not have to do anything, while for a connection-
702 oriented TML, this primitive call may be a signal for the TML to
703 disconnect all TML level connections to peering TML.
705 Another important point is, to better synchronize the operations
706 between peering PLs, a TML will have to discard all PL messages
707 received by the TML after the TML has been closed by local PL.
709 Hadi Salim Expires Oct., 2006 [Page 14]
710 5.5.TML Configuration
712 Syntax:
713 status = -- SUCCESS or errorIndication
714 TMLconfig(
715 IN operation
716 IN path
717 IN data
718 )
719 Parameters:
721 operation ?the operation type for the configuration. Two operations
722 are defined:
723 operation = ADD ?to add parameter
724 = DELETE ?to delete parameter
726 path ?a path composed of element ID(s) and (or) array index
727 pointing to the element to be configured.
728 (TBD)
730 data ?the data to be configured to the element.
731 (TBD)
733 Service Description:
734 This primitive is used by the PL to control the behavior of the TML
735 by the PL layer configuring the related property elements in the TML.
736 The element is indicated by the 'path'. The value to be configured to
737 the element is accessed by the 'data'.
739 5.6. TML Query
741 Syntax:
742 status = -- SUCCESS or errorIndication
743 TMLquery(
744 IN path
745 OUT data
746 )
747 Parameters:
749 path ?a path composed of element ID(s) and (or) array index
750 pointing to the element to be queried.
751 (TBD)
753 data ?the data returned by the query.
754 (TBD)
756 Service Description:
758 Hadi Salim Expires Oct., 2006 [Page 15]
759 This primitive is used by the PL to query the behavior of the TML.
760 The querying element is indicated by the 'path'. The value queried is
761 stored at the 'data' field. The TML executes the primitive by filling
762 out the data field with the queried value of the element.
764 5.7. TML send
766 Syntax:
767 status = -- SUCCESS or errorIndication
768 TMLsend(
769 IN msgDestID,
770 IN msgType,
771 IN msgPrio,
772 IN msgLength,
773 IN msgPDU,
774 )
776 Parameters:
777 msgDestID: the destination ID for the PL message to be sent
778 msgType: the message type for the PL message to be sent
779 msgPrio: the message priority for the PL message to be sent
780 msgLen: the message length to be sent
781 msgPDU: the ForCES protocol message to be sent in its PDU
783 Service Description:
784 In this service, the PL sends a message to one (unicast) or more
785 (multicast) peer PLs via the TML. Note that this primitive includes
786 all parameters that are necessary for TML to manage transmission of
787 the PL message, therefore, there is no need for the TML to read in
788 the PL message body to retrieve this parameters. In this way, we may
789 decouple changes in ForCES protocol PDU (e.g., by the protocol update)
790 from TML level.
792 The msgDestID is used for the TML to find out TML layer transport
793 addresses for the message transmission. It also includes the
794 processing for PL message multicast transports, for the destination
795 ID may also be a multicast group ID.
797 The msgType is used for the TML to infer the requirements from PL
798 level for the manage sending, regarding its reliability, timeliness,
799 security, and congestion control. With this message type, it is easy
800 to recognize PL redirect messages from PL control messages.
801 Individual TML specifications should define how the msgTypes are used
802 to map into the TML requirements.
804 The msgPrio is used for the TML to meet the PL requirement for the
805 message transmission priority; it may also be used for TML to meet
806 the TML requirements for reliability, timeliness, security, and
807 congestion control. Individual TML specifications should define how
809 Hadi Salim Expires Oct., 2006 [Page 16]
810 the priority is mapped into the TML transport mechanisms for
811 prioritized transmission. Individual TML specifications may also
812 define how the priority is used for other TML requirements.
814 5.8. TML receive
816 Syntax:
817 status = -- SUCCESS or errorIndication
818 TMLreceive(
819 IN msgLength,
820 IN msgPDU,
821 )
823 Parameters:
824 msgLen: the length of the message received.
825 msgPDU: the received ForCES protocol message body in its PDU
826 format
828 Service Description:
829 This service is used for PL to synchronously receive PL messages
830 from peering TML.
832 Note that a PL message arrival event described before can also be
833 used for PL to receive PL messages from TML. The difference is that
834 this TML receive primitive makes PL to synchronously receive messages,
835 while a PL message arrival event receives messages in an asynchronous
836 way. Usually, an asynchronous method is more efficient in terms of
837 CPU cycles.
839 6. Theory of Operation
841 (TBD)
843 7. References
845 [RFC3654] Khosravi, et al., Requirements for Separation of IP
846 Control and Forwarding, RFC 3654, November 2003.
848 [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft-
849 ietf-forces-protocol-08.txt, work-in-progress, Mar. 2006.
851 [ForCES-Model] Yang, L., ForCES Forwarding Element Model, Aug. 2003,
852 http://www.ietf.org/internet-drafts/draft-ietf-forces-model-05.txt.
854 8. Author's Address
856 Weiming Wang
857 Zhejiang Gongshang University
858 149 Jiaogong Road
859 Hangzhou 310035
861 Hadi Salim Expires Oct., 2006 [Page 17]
862 P.R.China
863 Phone: +86-571-88071024
864 EMail: wmwang@mail.zjgsu.edu.cn
866 Jamal Hadi Salim
867 Znyx Networks
868 195 Stafford Rd. West
869 Ottawa, Ontario
870 Canada
871 Email: hadi@znyx.com
873 Appendix A. TML Attributes XML file
875 (TBD)
877 Intellectual Property Statement
879 The IETF takes no position regarding the validity or scope of any
880 Intellectual Property Rights or other rights that might be claimed to
881 pertain to the implementation or use of the technology described in
882 this document or the extent to which any license under such rights
883 might or might not be available; nor does it represent that it has
884 made any independent effort to identify any such rights. Information
885 on the procedures with respect to rights in RFC documents can be
886 found in BCP 78 and BCP 79.
888 Copies of IPR disclosures made to the IETF Secretariat and any
889 assurances of licenses to be made available, or the result of an
890 attempt made to obtain a general license or permission for the use of
891 such proprietary rights by implementers or users of this
892 specification can be obtained from the IETF on-line IPR repository at
893 http://www.ietf.org/ipr.
895 The IETF invites any interested party to bring to its attention any
896 copyrights, patents or patent applications, or other proprietary
897 rights that may cover technology that may be required to implement
898 this standard. Please address the information to the IETF at ietf-
899 ipr@ietf.org.
901 Disclaimer of Validity
903 This document and the information contained herein are provided on
904 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
905 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
906 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
907 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
908 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
909 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
911 Hadi Salim Expires Oct., 2006 [Page 18]
912 Copyright Statement
914 Copyright (C) The Internet Society (2006). This document is subject
915 to the rights, licenses and restrictions contained in BCP 78, and
916 except as set forth therein, the authors retain all their rights.
918 Acknowledgment
920 Funding for the RFC Editor function is currently provided by the
921 Internet Society.
923 Hadi Salim Expires Oct., 2006 [Page 19]