idnits 2.17.1
draft-halpern-forces-lfblibrary-base-01.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 14.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1191.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1168.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1175.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1181.
** 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 :
----------------------------------------------------------------------------
** There are 3 instances of too long lines in the document, the longest one
being 3 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 573 has weird spacing: '...igcally copie...'
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- 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 (March 5, 2006) is 6627 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)
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ForCES J. Halpern
3 Internet-Draft Self
4 Expires: September 6, 2006 March 5, 2006
6 A base Library for use with the ForCES Protocol and Model
7 draft-halpern-forces-lfblibrary-base-01
9 Status of this Memo
11 By submitting this Internet-Draft, each author represents that any
12 applicable patent or other IPR claims of which he or she is aware
13 have been or will be disclosed, and any of which he or she becomes
14 aware will be disclosed, in accordance with Section 6 of BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on September 6, 2006.
34 Copyright Notice
36 Copyright (C) The Internet Society (2006).
38 Abstract
40 The Forwarding and Control Element Separation (ForCES) working group
41 is defining a protocol to allow a Control Element (CE) to control the
42 behavior of a Forwarding Element (FE). The manipulations used by
43 this protocol operate in terms of adjustments to Logical Function
44 Blocks (LFBs) whose structure is defined my a model RFC produced by
45 the working group. In order to build an actual solution using this
46 protocol, there needs to be a set of Logical Function Block
47 definitions that can be instantiated by FEs and controlled by CEs.
48 This document provides an initial set of such definitions. It is
49 anticipated that additional defining documents will be produced over
50 time.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
56 3. Base Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
57 4. Connectivity LFBs . . . . . . . . . . . . . . . . . . . . . . 4
58 4.1. Generic Connectivity LFB . . . . . . . . . . . . . . . . . 4
59 4.2. Redirect LFB . . . . . . . . . . . . . . . . . . . . . . . 6
60 4.3. taggedInterface . . . . . . . . . . . . . . . . . . . . . 8
61 5. Packet Validation and Manipulation LFBs . . . . . . . . . . . 8
62 5.1. IPv4 Validator LFB . . . . . . . . . . . . . . . . . . . . 8
63 5.2. IPv6 Validator LFB . . . . . . . . . . . . . . . . . . . . 9
64 5.3. Meta-Data marker . . . . . . . . . . . . . . . . . . . . . 11
65 5.4. Packet Trimmer . . . . . . . . . . . . . . . . . . . . . . 12
66 5.5. IPv4 outbound updater . . . . . . . . . . . . . . . . . . 13
67 5.6. IPv6 outbound updater . . . . . . . . . . . . . . . . . . 13
68 5.7. Duplicator . . . . . . . . . . . . . . . . . . . . . . . . 13
69 6. Classifer LFBs . . . . . . . . . . . . . . . . . . . . . . . . 14
70 6.1. Classifier Data Types . . . . . . . . . . . . . . . . . . 15
71 6.2. ArbitraryClassifierLfb . . . . . . . . . . . . . . . . . . 21
72 6.3. LPMClassifier . . . . . . . . . . . . . . . . . . . . . . 24
73 6.4. Next Hop Applicator . . . . . . . . . . . . . . . . . . . 24
74 7. Packet Control LFBs . . . . . . . . . . . . . . . . . . . . . 24
75 7.1. ARPOutRequestLFB . . . . . . . . . . . . . . . . . . . . . 25
76 7.2. ARPInMessageLFB . . . . . . . . . . . . . . . . . . . . . 25
77 7.3. ICMPLFB . . . . . . . . . . . . . . . . . . . . . . . . . 25
78 8. Queue and Scheduler LFBs . . . . . . . . . . . . . . . . . . . 25
79 8.1. Scheduler . . . . . . . . . . . . . . . . . . . . . . . . 26
80 8.2. Queue . . . . . . . . . . . . . . . . . . . . . . . . . . 26
81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
82 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
84 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
86 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
87 13.2. Informative References . . . . . . . . . . . . . . . . . . 27
88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
89 Intellectual Property and Copyright Statements . . . . . . . . . . 29
91 1. Introduction
93 The ForCES protocol Protocol [2] defines a protocol by whcih Control
94 Elements (CEs) communicated with and control the behavior of
95 Forwarding Elements (FEs). That control is expressed in terms of
96 manipulations of attributes of Logical Function Blocks (LFBs). The
97 structure and abstract semantics of LFBs is defined in Model [3].
98 That document also defines a single LFB Class for gaining access to
99 FE properties including the set of LFBs and their interconnection.
100 The Protocol [2] document defines an LFB class for manipulating the
101 protocol properties of the FE.
103 In order for the protocol to be useful to control any behavior, there
104 must be a set of LFB class definitions for the LFBs which provide
105 that behavior. This document provides an initial set of such
106 definitions. While this document is intended to provide an initially
107 sufficient set of such classes, it is expected that other definitions
108 will be developed over time, and documented in other RFCs.
110 Section 3 provides a set of definitions, in an LFBLibrary wrapper
111 that does not provide any classes. These are then used in each
112 subsequent definition by the statement:
114
116 Following that are sections containing definitions of LFB classes.
117 They are group for convenience. While there is some explanatory text
118 in each section, the primary semantics are explain in description
119 clauses in the LFB Class definition so as to ensure the description
120 is available in any context that uses the definition.
122 [Editor's note: Most of these class definitions are completely blank.
123 A few have been filled in to provide starting ideas to contributors.]
125 2. Requirements notation
127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
129 document are to be interpreted as described in [1].
131 3. Base Definitions
133 This section povides a base set of LFB frame, data type, and meta
134 data definitions for use by all any LFB Class definitions (in this or
135 other documents. This section provides no actual LFB Class
136 definitions.
138
139
140
141 IPv4Frame
142 A frame containing an IPv4 packet.
143
144
145 IPv6Frame
146 A frame containing an IPv6 packet.
147
148
149 taggedFrame
150 A frame of any type with associated metadata.
151
152
153 metaDataFrame
154
155 A frame consisting only of meta data, with no packet.
156
157
158
159
160
161
162
163
165 4. Connectivity LFBs
167 This section provides LFB class definitions for LFBs which provide
168 connectivity between the FE and the rest of the world.
170 4.1. Generic Connectivity LFB
172 This section provides the LFB Class definition for the generic
173 connectivity LFB. This LFB is intended to provide media and
174 encapsulation oriented capabilities such as one might associated with
175 an interface. It only captures those properties which relate to its
176 function in the data flow. (So, for example, it does not provide for
177 the IP address associated with this interface, or even an indication
178 as to whether there is such an address.)
179
180
181
182
183 GenericConnectivityLFB
184
185 An LFB Class for providing connectivity between an FE and
186 communications media.
187
188 0.0
189
190 This LFB Class provides a generic basis for representing
191 connectivity between the FE and the outside world.
193 The LFB has one or more ports for packets that the FE
194 processing logic is forwrding for transmission by this
195 Connectivity LFB. It has one or more ports for packets
196 that the Connectivity LFB has received and is handing to
197 the FE processing logic.
199 Multiple ports for handline packets are supported so that
200 protocol specific encapsulation and demultiplexing can be
201 provided by this LFB.
203 This LFB also has ports for sending packets to lower layer
204 Connectivity LFBs and receiving packets from such lower
205 layer Connectivity LFBs. This enables support for the
206 processing components of interface stacks, such as PPP over
207 Ethernet or Ethernet over MPLS.
209 For packets arriving from Media or lower layer connectivity,
210 this LFB will perform appropriate media validation, then
211 remove media specific headers, and place the relevant
212 information in meta-data. For ethernet, the Source MAC would
213 be in meta-data. For Frame Relay or ATM, a circuit identifier
214 would be in meta-data. For Ethernet with VLANs, this
215 meta-data would indicate which VLAN the packet came from.
217 For packets to be transmitted, meta-data indicating the
218 destination (destination MAC or outgoing circuit, etc.) is
219 required.
221 This LFB will also include statistical attributes such as the
222 number of octets and packets sent and received, the number of
223 various input and output errors, etc.
224
225
226
228
230 4.2. Redirect LFB
232 This class definition provides for the function of sending and
233 receiving data packets between the CE and the FE. Such data packets
234 are accompanied by meta-data which assists the receiver processing of
235 the packet. This LFB is implicitly tied to the protocol machinery
236 for redirecting packets.
238 There may be multiple Redirect LFBs in the LFB topology. For packets
239 from the CE to the FE, as described in Protocol [2] the correct LFB
240 to handle the packet is determined by the instance ID in the redirect
241 message. In the direction from the FE to the CE, the source instance
242 ID indicates which LFB is sending the packet. Redirect Source or
243 Sink LFBs may be instantiated by simply not connecting the input or
244 output ports of the LFB instance to any other portion of the
245 topology.
247
248
249
250
251 RedirectLFB
252
253 An LFB Class definition for exchanging data packets
254 between the FE and the CE.
255
256 0.0
257
258
259 RedirectToCE
260
261 Port for frames to send to the CE.
262
263
264
265 taggedFrame
266
267
268
269
270
271
272 RedirectFromCE
273
274 Port for frames to send to the CE
275
276
277 taggedFrame
278
279
280
281
282 This LFB represents a point of exchagne of data packets
283 between the CE and the FE. Packets with meta-data are
284 exchanged. It is expected that the output port of a
285 RedirectLFB, if it is connected at all, will be connected
286 to a meta-data redirector.
287
288
289
290
292 4.3. taggedInterface
294 This LFB is for use instead of a GenericConnectivity LFB for use in
295 conjunction with media interfaces which can carry meta-data. It is
296 in some ways similar to the RedirectLFB. It is expected that it will
297 be used with media that are used to interconnect FEs, such as modern
298 chassis fabrics, which can carry meta-data with packets. Unlike the
299 Redirect LFB, it is expected that for a given fabric an FE will have
300 only one taggedInterface LFB instance.
302 5. Packet Validation and Manipulation LFBs
304 This section provides LFBs that verify or adjust contents of packets.
305 While one could consider the classifiers a subset of this, they are
306 sufficiently significant that they are dealt with separately.
308 5.1. IPv4 Validator LFB
310 This LFB validates the IP version and header length fields, including
311 verifying that the packet length is at least as long as the header
312 indicates.
314 This may be placed in the data path following a Connectivity LFB, or
315 it may be placed in the data path for packets directed towards the
316 CE, as some routers choose not to perform extensive validation on
317 data packets to be forwarded.
319
320
321
322
323 IPv4Validator
324
325 An LFB Class definition for validates the IPv4 packet.
326
327 1.0
328
329
330 ValidatorIn
331
332 Normal packet input.
333
334
335
336 [IPv4]
337
339
340
341
342
343
344 ValidatorOut
345
346 Normal packet Output.
347
348
349
350 [IPv4packet]
351
352
353
354
355 FailOutput
356
357 The port to send packets that do not match any entries.
358
359
360
361 [taggedFrame]
362
363
364 [errorid]
365
366
367
368
369
370 This LFB validates the IP version and header length
371 fields, including verifying that the packet length
372 is at least as long as the header indicates.
373
374
375
376
378 5.2. IPv6 Validator LFB
380 This LFB validates the IP version and header length fields, including
381 verifying that the packet length is at least as long as the header
382 indicates.
384 This may be placed in the data path following a Connectivity LFB, or
385 it may be placed in the data path for packets directed towards the
386 CE, as some routers choose not to perform extensive validation on
387 data packets to be forwarded.
389
390
391
392
393 ErrorId
394 Error Type.
395 11
396
397 int32
398
399
400 WrongIpVersion
401 the IP version wrong
402
403
404 WrongLength
405
406 the packet length is not as long as
407 the header indicates
408
409
410
411 otherError
412 The errors we not defined now
413
414
415
416
417
418
419
420 IPv6Validator
421
422 An LFB Class definition for validates the IPv6 packet.
423
424 1.0
425
426
427 ValidatorIn
428
429 Normal packet input.
430
431
432
433 [IPv6]
434
435
436
437
438
439
440 ValidatorOut
441
442 Normal packet Output.
443
444
445
446 [IPv6packet]
447
448
449
450
451 FailOutput
452
453 The port to send packets that do not match any entries.
454
455
456
457 [taggedFrame]
458
459
460 [errorid]
461
462
463
464
465
466 This LFB validates the IP version and header length
467 fields, including verifying that the packet length
468 is at least as long as the header indicates.
469
470
471
472
474 5.3. Meta-Data marker
476 It is sometimes necessary to move information from the packet to
477 meta-data, or from one meta-data field to another. This LFB class
478 provides that capability. It consists of a series of processing
479 instructions. Each instruction identifes either a meta-data element,
480 a named packet field, or a portion of the packet identified by offset
481 and length. The instruction also indicates what meta-data element to
482 copy the selected data into. The target field is identified using
483 the same data types used for the matcher target identification.
485 5.4. Packet Trimmer
487 It is sometimes necessary to remove data from the front of a packet.
488 This LFB class provides that capability.
490
491
492
493
494 PacketTrimmer
495
496 LFB removes data from the front of a packet.
497
498 1.0
499
500
501 PacketIn
502
503 Normal packet input.
504
505
506
507 [Packet]
508
509
510
511
512
513
514 PacketOut
515
516 Normal packet Output.
517
518
519
520 [Packet]
521
522
523
524
525 FailOut
526
527 For packets without enough bytes to remove
528
529
530
531 [Packet]
532
533
534
535
536
537
538 TrimLength
539 amount to trim from each packet
540 uint32
541
542
543
544
545
547 5.5. IPv4 outbound updater
549 This LFB updates the TTL and header checksum in a packet to be sent
550 by the FE. The header checksum update is performed by modification,
551 so that erroneous checksums are still erroneous.
553 5.6. IPv6 outbound updater
555 This LFB updates the TTL and header checksum in a packet to be sent
556 by the FE. The header checksum update is performed by modification,
557 so that erroneous checksums are still erroneous.
559 5.7. Duplicator
561 A duplicator LFB has one input port and multiple output ports. Any
562 packet arriving on an input port is copied so as to be sent on all
563 output ports.
565
566
567
568
569 Duplicator
570
571 An LFB Class definition for packet duplicator LFB.
572 Any packet received on an input port is
573 loigcally copied and sent to all output ports.
574
575 1.0
576
577
578 PacketIn
579
580 Normal packet input.
581
582
583
584 [IPv4]
585 [IPv6]
586
587
588
589
590
591
592 PacketOut
593 Normal packet output port group
594
595
596 [IPv4]
597 [IPv6]
598
599
600
601
602
603
604
606 6. Classifer LFBs
608 This section provides the classifer LFBs. It also includes a set of
609 data type definitions for use by classifiers.
611 Currently, two classifiers are defined here. One has the ability to
612 classify a packet based on combinations of meta data and packet
613 contents. It has the ability to add meta-data, and to select an
614 egress port. It may be useful to define classes with only a subset
615 of these capabilities. The other does an longest prefix match (LPM)
616 lookup of the value provided in the "target" meta-data item.
618 6.1. Classifier Data Types
620 These data definitions belong in a dataTypeDefs element in some
621 LFBLibrary.
623 These data definitions are built around a simplistic classifier
624 model. The classifier consists of a sequence of test-action pairs.
625 The each test consists of an optional input port number condition
626 followed by a sequence of match conditions. A test is considered
627 passed if all of the match conditions succeed. The classifier
628 conceptually functions by applying success tests until one succeeds.
630 First, there is the definition of the scalar for the target of a
631 match.
633
634 MatchTargetType
635
636 Indicator for the kind of field to be matched by this
637 entry in a classifier.
638
639
640 uint8
641
642
643 MatchNone
644 A matcher against no field
645
646
647 MatchMetaData
648 A matcher against a metadata item
649
650
651 MatchPacketField
652
653 A matcher that works against an identified packet field.
654
655
656 MatchOffsetLength
657
658 The match target is a specified portion of the packet.
659
660
661
662
663
665 Then there is the data type definition for the identifier of the
666 target of the match.
668
669 MatchTargetIdentifier
670
671 Identify the specific target of a match condition.
672
673
674
675 MetaDataID
676 The ID of a metadata item
677 uint32
678
679
680 packetFieldID
681
682 The identifier for a packet Field, such as SA, DA,
683 Protocol, SPort, DPort, etc. These identifiers allow
684 references to fields with varialbe amounts before them.
685
686 uint32
687
688
689 OffSetLengthPacketField
690
691 A field in the packet identified by its offset and
692 length in bits. This does not allow for matching fields
693 whose position depends upon earlier field sizes.
694
695
696
697 fieldOffset
698
699 The offset in bits from the start of the packet to the
700 start of the field.
701
702 uint32
703
704
705 fieldLength
706 The length of the field, in bits
707 uint32
708
709
710
711
712
714 Then there is the representation of the match condition. First we
715 provide the structure definition for a match condition, and then the
716 enumeration that defines the various conditions. This ordering is
717 for readability.
719 The conditions use bitfields, which are represented as octet strings
720 of length up to 16 bytes, along with a length providing the actual
721 meaningful length in bits. The model could be enhanced to provide a
722 base type for variable length bit strings.
724
725 MatchBitString
726 A bit string for use in a match condition.
727
728
729 MatchBits
730 The bits to match
731 OctetString[16]
732
733
734 MatchLength
735 The number of bits to match
736 uint8
737
738
739
741
742 MatchCondition
743
744 structure for a single condition to be applied.
745
746
747
748 TargetType
749 The category of target to match
750 MatchTargetType
751
752
753 TargetID
754 The specific target to compare
755 MatchTargetIdentifier
756
757
758 MatchType
759 The kind of match to apply.
760 MatchConditionType
761
762
763 MatchParamOne
764 The first parameter for the match
765
766 MatchBitString
767
768 MatchParamTwo
769 The second parameter for the match
770
771 MatchBitString
772
773
774
776 The enumeration describes the match types, and how it interacts with
777 the structure of a match condition. There may be more conditions
778 here than we need.
780
781 MatchConditiontType
782
783 Indicator for the kind of match condition to be applied.
784
785
786 uint8
787
788
789 MatchNone
790 A matcher which always fails
791
792
793 MatchExact
794
795 The target and the match value must be the same, with no
796 padding. Only the first value of the match condition is
797 used. The first match value must be occur.
798
799
800
801 MatchLeft
802
803 The target must begin with the first match value.
804 If there is a second match value, the remainder of the
805 target must match repeated occurrances of the second
806 value. Thus, this can be used to allow any terminal
807 content, or specific ending pad. The first match value
808 must occur.
809
810
811
812 MatchRight
813
814 The target must end with the first match value.
815 If there is a second match value, the preceding part
816 of the target must match repeated occurrances of the
817 second value. Thus, this can be used to allow any
818 leading content, or specific leading fill. The first
819 match value must occur.
820
821
822
823 MatchRange
824
825 The match values will be considered as numbers, and
826 the target must be greater than or equal to the
827 first match value, and less than or equal to the
828 second match value. An omitted match value means
829 that end of the range is unlimitted.
830
831
832
833 MatchMaskedValue
834
835 The target the the first value are each anded with the
836 second value. The match succeeds if the results of these
837 and operations are identical. Both values are required.
838
839
840
841 MatchSucceed
842 A Match which always succeeds
843
844
845
846
848 The MatchMetaData Action represents setting a piece of metadata when
849 all of the match conditions are met. The action can set the meta-
850 data to a specific value, or can set it to a value used by a match
851 condition.
853 The two kinds of values are used, without a union, for simplicity.
855 The match condition value is used as that avoids the question of
856 whether a specific field exists in the packet. It must exist for it
857 to have matched.
859
860 MatchMetaDataAction
861
862 An action to set a metadata item to either a specific value
863 or a field from the incoming meta data or packet.
864
865
866
867 MetaDataToSet
868 The Meta Data Item to set
869 uint32
870
871
872 ExplicitValueToSet
873 A value to set the metadata to
874
875 OctetString[16]
876
877
878 ValueFromCondition
879
880 This is an index into the corresponding match conditions,
881 and the meta data will be set to the value that was tested
882 by that condition.
883
884
885 uint32
886
887
888
890 6.2. ArbitraryClassifierLfb
892 This is a class definition that makes use of the above types. The
893 input is a port group, and the match conditions can include the port
894 in their test. This allows the topology to carry some information if
895 desired. The match conditions can select an output from the
896 SuccessOuput output port group. If no condition matches, the packet
897 will be sesnt to the FailOutput port.
899
900
901
902
903 ArbitraryClassifierLfb
904
905 A classifier which can test packet or metadata, and on that
906 basis set meta-data a pick an output port.
907
908 0.0
909
910
911 PacketsToClassify
912
913 The group of ports to received packets over
914
915
916
917 [taggedFrame]
918
919
920
921
922
923
924
925 SuccessOutput
926
927 The group of ports used by the classifer for output
928 when a successful match is found.
929
930
931
932 [taggedFrame]
933
934
935
936
937
938 FailOutput
939
940 The port to send packets that do not match any entries.
941
942
943
944 [taggedFrame]
945
946
947
949
950
951
952
953 ClassifierTable
954
955 The table of classifier entries
956 Each entry is tested until one succeeds.
957 Each entry contains an optional port test, an array of
958 packet and meta data tests, an array of metadata actions,
959 and an exit selection.
960
961
962
963
964 InputPortTest
965
966 If present, this match will only match packets
967 arriving over the specified port.
968
969
970 uint32
971
972
973 TestConditions
974 The array of conditions to test
975
976 MatchCondition
977
978
979
980 MetaDataActions
981
982 The array of meta data modifications to make when the
983 match succeeds.
984
985
986 MatchMetaDataAction
987
988
989
990 MatchOutputPort
991
992 The port within the success group to send packets
993 which match these tests.
994
995 uint32
996
998
999
1000
1001
1002
1003
1004
1005
1006
1008 6.3. LPMClassifier
1010 This takes the information in the "target" metadata item, and looks
1011 it up in its longest prefix match table. It sets the "LPMresult"
1012 meta-data item to the value associated with the best match entry.
1013 For example, the result might be a next-hop identifier.
1015 6.4. Next Hop Applicator
1017 This LFB class is used to apply a next hop to a packet. The next hop
1018 is identified by the NextHop meta-data. The value of that meta-data
1019 is used as an index into the next-hop table owned by this instance of
1020 this class. The table indicates a series of new meta-data items to
1021 add to the packet, and an exit port from the Success port group. If
1022 no valid next hop is found, the packet is sent to the MissingEntry
1023 port. If a valid next hop is found, but it needs resolution, the
1024 packet is sent to the NeedsResolution port, which will typically lead
1025 to a suitable ARPOutRequest LFB instance.
1027 As part of the functioning of this LFB, one of the next hop
1028 identifiers would indicate packets to be sent to the CE. One of the
1029 outputs of this Next Hop applicator would be connected to a path
1030 leading to a Redirect LFB to handle those packets.
1032 Note that some FEs will have restrictions in their actual
1033 implementation such that the LPM always goes against certain packet
1034 fields, and always produces a block of information rather than an
1035 identifier. Some of those restrictions can be represented by the FE
1036 Object LFB Support LFB Attribute CanOccurBefores and CanOccurAfters
1037 information.
1039 7. Packet Control LFBs
1041 These LFBs are related to control functions for data packets.
1043 7.1. ARPOutRequestLFB
1045 Given a data packet and a next hop identifier, this LFB builds an ARP
1046 request and hands it off. It has an alias to point to the next hop
1047 table that is shared with the output encapsulor in the connectivity
1048 LFB and with other packet processors.
1050 7.2. ARPInMessageLFB
1052 This LFB is handed received ARP messges, both requests and responses.
1053 It performs table updating (using alias entries) and when necessary
1054 generates ARP responses.
1056 7.3. ICMPLFB
1058 This is handed a packet with meta-data indicating a problem. It
1059 determines if an ICMP message should be generated, and if so to whom
1060 it should be sent.
1062 8. Queue and Scheduler LFBs
1064 To build an actual forwarder, one must include some limitted for of
1065 queueing and scheduling. Queues are entities which store packets.
1066 Schedulers are entities which react to the state of queues and cause
1067 packets to be emitted from queues.
1069 The actual interaction between queues and schedulers (and their real
1070 world degree of separation) is quite complex. A very complex LFB
1071 model would be required to represent all the complexity.
1072 Additionally, there is the issue of representing the relationship
1073 between the queue and the scheduler. A simple approach has been
1074 taken in these class definitions.
1076 A queue element consists of an input port (called InData) on which it
1077 receives data packets, and output port (called OutData) on which it
1078 will send packets when permitted by its definition or the scheduler.
1079 Its relationship to scheduluers is represented by a set of output
1080 ports (the group OutCountrol) and an input port (called InControl).
1081 These ports are defined to carry packets consisting only of meta-
1082 data. In fact, these ports are an abstraction, and what one might
1083 call a legal fiction. An element of the OutControl group represents
1084 the fact that a scheduler is aware of the state of that queue
1085 element. The InControl port represents the fact that one or more
1086 schedulers connected to that port are controlling that queue. There
1087 is no meta-data defined for actual exchange on these ports, as their
1088 real world realization is highly implementation dependent. To
1089 complete this picture, a schedule has a group of input ports
1090 (Watchers) representing the connectivity to queues it is aware of,
1091 and a group of output ports (Controllers) representing control over
1092 queues. This allows for the simple case of a controller who monitors
1093 and controls a single set of queues, and more interesting cases where
1094 the control of certain queues may depend upon the state of queues
1095 whihc are not under the control of the scheduler.
1097 8.1. Scheduler
1099 This defines a base LFB class for schedulers. Scheulers have an
1100 Input Port group called Watchers for representing the queues they
1101 watch, and an Output Port group called Controllers fro representing
1102 the queues they control.
1104 8.2. Queue
1106 Queues have a packet input, a packet output, a control input, and a
1107 group of control outputs. The control ports represent the control
1108 relationships with scheduluers.
1110 9. Acknowledgements
1112 The ideas here are based on proposals from many people. In
1113 particular, Xiaoyi Guo has provided some of the LFB definitions
1114 included herein.
1116 10. Contributors
1118 The following people contributed significant portions of text to this
1119 document.
1121 11. IANA Considerations
1123 The ForCES working group needs to determine how LFB Class IDs will be
1124 registered. It seems likely that an IANA registry will be needed.
1125 Once that registry is established by the Model draft, this document
1126 will need to register values for the LFB classes it defines.
1128 12. Security Considerations
1130 These definitions if used by an FE to support ForCES create
1131 manipulable entities on the FE. Manipulation of such objects can
1132 produce almost unlimited effects on the FE. FEs should ensure that
1133 only properly authenticated ForCES protocol participants are
1134 performing such manipulations. Thus, largely, the security issues
1135 with this protocol are defined in Protocol [2].
1137 13. References
1139 13.1. Normative References
1141 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1142 Levels", BCP 14, RFC 2119, March 1997.
1144 [2] Doria, A., "I-D.ietf-forces-protocol-04.txt", 2005.
1146 [3] Deleganes, E., "I-D.ietf-forces-model-05.txt", 2005.
1148 13.2. Informative References
1149 Author's Address
1151 Joel M. Halpern
1152 Self
1153 P. O. Box 6049
1154 Leesburg, VA 20178
1155 US
1157 Email: jmh@joelhalpern.com
1159 Intellectual Property Statement
1161 The IETF takes no position regarding the validity or scope of any
1162 Intellectual Property Rights or other rights that might be claimed to
1163 pertain to the implementation or use of the technology described in
1164 this document or the extent to which any license under such rights
1165 might or might not be available; nor does it represent that it has
1166 made any independent effort to identify any such rights. Information
1167 on the procedures with respect to rights in RFC documents can be
1168 found in BCP 78 and BCP 79.
1170 Copies of IPR disclosures made to the IETF Secretariat and any
1171 assurances of licenses to be made available, or the result of an
1172 attempt made to obtain a general license or permission for the use of
1173 such proprietary rights by implementers or users of this
1174 specification can be obtained from the IETF on-line IPR repository at
1175 http://www.ietf.org/ipr.
1177 The IETF invites any interested party to bring to its attention any
1178 copyrights, patents or patent applications, or other proprietary
1179 rights that may cover technology that may be required to implement
1180 this standard. Please address the information to the IETF at
1181 ietf-ipr@ietf.org.
1183 Disclaimer of Validity
1185 This document and the information contained herein are provided on an
1186 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1187 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1188 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1189 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1190 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1191 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1193 Copyright Statement
1195 Copyright (C) The Internet Society (2006). This document is subject
1196 to the rights, licenses and restrictions contained in BCP 78, and
1197 except as set forth therein, the authors retain all their rights.
1199 Acknowledgment
1201 Funding for the RFC Editor function is currently provided by the
1202 Internet Society.