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.