idnits 2.17.1 draft-ietf-forces-lfb-lib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5810], [RFC5812]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2010) is 4940 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'N' is mentioned on line 379, but not defined == Unused Reference: 'RFC1812' is defined on line 3629, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 3635, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 3638, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 3649, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Wang 3 Internet-Draft Zhejiang Gongshang University 4 Intended status: Standards Track E. Haleplidis 5 Expires: April 20, 2011 University of Patras 6 K. Ogawa 7 NTT Corporation 8 F. Jia 9 National Digital Switching 10 Center(NDSC) 11 J. Halpern 12 Ericsson 13 October 17, 2010 15 ForCES LFB Library 16 draft-ietf-forces-lfb-lib-02 18 Abstract 20 This document defines basic classes of Logical Function Blocks (LFBs) 21 used in the Forwarding and Control Element Separation (ForCES). It 22 is defined according to ForCES FE model [RFC5812] and ForCES protocol 23 [RFC5810] specifications. The basis classes of LFBs are defined to 24 meet requirements of typical router functions. Descriptions of 25 individual classes of LFBs are presented and detailed XML definitions 26 are included. As use instances, several use cases of the defined 27 classes of LFBs to meet typical router functions are proposed in the 28 document. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 20, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . . 7 68 3.2. Overview of LFB Classes in the Library . . . . . . . . . . 9 69 3.3. Document Structure . . . . . . . . . . . . . . . . . . . . 10 70 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.1. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.2. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.3. MetaData . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 12 75 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 31 76 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 31 77 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 31 78 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . . 33 79 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 35 80 5.1.4. EtherEncapsulator . . . . . . . . . . . . . . . . . . 36 81 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 40 82 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 40 83 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 41 84 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 41 85 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 42 86 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . . 43 87 5.3.2. IPv4NextHopApplicator . . . . . . . . . . . . . . . . 44 88 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . . 46 89 5.3.4. IPv6NextHopApplicator . . . . . . . . . . . . . . . . 46 90 5.4. Address Resolution LFBs . . . . . . . . . . . . . . . . . 46 91 5.4.1. ARP . . . . . . . . . . . . . . . . . . . . . . . . . 46 92 5.4.2. ND . . . . . . . . . . . . . . . . . . . . . . . . . . 48 93 5.5. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 48 94 5.5.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . . 48 95 5.5.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 49 96 5.6. General Purpose LFBs . . . . . . . . . . . . . . . . . . . 49 97 5.6.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 49 98 5.6.2. GenericScheduler . . . . . . . . . . . . . . . . . . . 50 99 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 52 100 7. Use Library for Typical Router Functions . . . . . . . . . . . 77 101 7.1. IP Forwarding . . . . . . . . . . . . . . . . . . . . . . 77 102 7.2. Address Resolution . . . . . . . . . . . . . . . . . . . . 78 103 7.3. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 104 7.4. Running Routing Protocol . . . . . . . . . . . . . . . . . 79 105 7.5. Network Management . . . . . . . . . . . . . . . . . . . . 79 106 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 80 107 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 109 11. Security Considerations . . . . . . . . . . . . . . . . . . . 83 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 111 12.1. Normative References . . . . . . . . . . . . . . . . . . . 84 112 12.2. Informative References . . . . . . . . . . . . . . . . . . 84 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85 115 1. Terminology and Conventions 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Definitions 125 This document follows the terminology defined by the ForCES 126 Requirements in [RFC3654]and by the ForCES framework in [RFC3746]. 127 The definitions below are repeated below for clarity. 129 Control Element (CE) - A logical entity that implements the ForCES 130 protocol and uses it to instruct one or more FEs on how to process 131 packets. CEs handle functionality such as the execution of 132 control and signaling protocols. 134 Forwarding Element (FE) - A logical entity that implements the 135 ForCES protocol. FEs use the underlying hardware to provide per- 136 packet processing and handling as directed/controlled by one or 137 more CEs via the ForCES protocol. 139 ForCES Network Element (NE) - An entity composed of one or more 140 CEs and one or more FEs. To entities outside an NE, the NE 141 represents a single point of management. Similarly, an NE usually 142 hides its internal organization from external entities. 144 LFB (Logical Function Block) - The basic building block that is 145 operated on by the ForCES protocol. The LFB is a well defined, 146 logically separable functional block that resides in an FE and is 147 controlled by the CE via ForCES protocol. The LFB may reside at 148 the FE's datapath and process packets or may be purely an FE 149 control or configuration entity that is operated on by the CE. 150 Note that the LFB is a functionally accurate abstraction of the 151 FE's processing capabilities, but not a hardware-accurate 152 representation of the FE implementation. 154 FE Topology - A representation of how the multiple FEs within a 155 single NE are interconnected. Sometimes this is called inter-FE 156 topology, to be distinguished from intra-FE topology (i.e., LFB 157 topology). 159 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. 160 An LFB Instance represents an LFB Class (or Type) existence. 161 There may be multiple instances of the same LFB Class (or Type) in 162 an FE. An LFB Class is represented by an LFB Class ID, and an LFB 163 Instance is represented by an LFB Instance ID. As a result, an 164 LFB Class ID associated with an LFB Instance ID uniquely specifies 165 an LFB existence. 167 LFB Metadata - Metadata is used to communicate per-packet state 168 from one LFB to another, but is not sent across the network. The 169 FE model defines how such metadata is identified, produced and 170 consumed by the LFBs. It defines the functionality but not how 171 metadata is encoded within an implementation. 173 LFB Component - Operational parameters of the LFBs that must be 174 visible to the CEs are conceptualized in the FE model as the LFB 175 components. The LFB components include, for example, flags, 176 single parameter arguments, complex arguments, and tables that the 177 CE can read and/or write via the ForCES protocol (see below). 179 LFB Topology - Representation of how the LFB instances are 180 logically interconnected and placed along the datapath within one 181 FE. Sometimes it is also called intra-FE topology, to be 182 distinguished from inter-FE topology. 184 ForCES Protocol - While there may be multiple protocols used 185 within the overall ForCES architecture, the term "ForCES protocol" 186 and "protocol" refer to the Fp reference points in the ForCES 187 Framework in [RFC3746]. This protocol does not apply to CE-to-CE 188 communication, FE-to-FE communication, or to communication between 189 FE and CE managers. Basically, the ForCES protocol works in a 190 master- slave mode in which FEs are slaves and CEs are masters. 191 This document defines the specifications for this ForCES protocol. 193 3. Introduction 195 RFC 3746 [RFC3746] specifies Forwarding and Control Element 196 Separation (ForCES) framework. In the framework, Control Elements 197 (CEs) configure and manage one or more separate Forwarding Elements 198 (FEs) within a Network Element (NE) by use of a ForCES protocol. RFC 199 5810 [RFC5810] specifies the ForCES protocol. RFC 5812 [RFC5812] 200 specifies the Forwarding Element (FE) model. In the model, resources 201 in FEs are described by classes of Logical Function Blocks (LFBs). 202 The FE model defines the structure and abstract semantics of LFBs, 203 and provides XML schema for the definitions of LFBs. 205 This document comforts to the specifications of the FE model 206 [RFC5812] and specifies detailed definitions of classes of LFBs, 207 including detailed XML definitions of LFBs. These LFBs form a base 208 LFB library for ForCES. LFBs in the base library are expected to be 209 combined to form an LFB topology for a typical router to implement IP 210 forwarding. It should be emphasized that an LFB is an abstraction of 211 functions rather than its implementation details. The purpose of the 212 LFB definitions is to represent functions so as to provide 213 interoperability between separate CEs and FEs. 215 More LFB classes with more functions may be developed in future time 216 and documented by IETF. Vendors may also develop their individual 217 LFB classes according to the FE model [RFC5812] for their specific 218 purposes. 220 3.1. Scope of the Library 222 It is designated that the LFB classes described in this document are 223 designed to provide the functions of a typical router. RFC 1812 224 specifies that a typical router is expected to provide functions to: 226 (1) Interface to packet networks and implement the functions required 227 by that network. These functions typically include: 229 o Encapsulating and decapsulating the IP datagrams with the 230 connected network framing (e.g., an Ethernet header and checksum). 232 o Sending and receiving IP datagrams up to the maximum size 233 supported by that network, this size is the network's Maximum 234 Transmission Unit or MTU. 236 o Translating the IP destination address into an appropriate 237 network-level address for the connected network (e.g., an Ethernet 238 hardware address), if needed, and 240 o Responding to network flow control and error indications, if any. 242 (2) Conform to specific Internet protocols including the Internet 243 Protocol (IPv4 and/or IPv6), Internet Control Message Protocol 244 (ICMP), and others as necessary. 246 (3) Receive and forwards Internet datagrams. Important issues in 247 this process are buffer management, congestion control, and fairness. 249 o Recognizes error conditions and generates ICMP error and 250 information messages as required. 252 o Drops datagrams whose time-to-live fields have reached zero. 254 o Fragments datagrams when necessary to fit into the MTU of the next 255 network. 257 (4) Choose a next-hop destination for each IP datagram, based on the 258 information in its routing database. 260 (5) Usually support an interior gateway protocol (IGP) to carry out 261 distributed routing and reachability algorithms with the other 262 routers in the same autonomous system. In addition, some routers 263 will need to support an exterior gateway protocol (EGP) to exchange 264 topological information with other autonomous systems. 266 (6) Provide network management and system support facilities, 267 including loading, debugging, status reporting, exception reporting 268 and control. 270 Within the ForCES framework, according to the ForCES protocol 271 [RFC5810] and the FE model [RFC5812] specifications, above typical 272 router functions should be implemented under the concept of Logical 273 Functional Blocks (LFBs). Taking a typical IP forwarding function as 274 an example, some port LFBs receive packets and decapsulate the IP 275 datagrams to form IP level packets. Different port media have 276 different manipulating requirements from CE, therefore various port 277 LFBs for various media may have to be defined. IP packets from port 278 LFBs are then validated before being further forwarded. A kind of 279 valildation LFBs are applied for the purpose. After validation 280 process, some LFBs for IP forwarding may then be applied. In the 281 Forwarding LFBs, a Longest Prefix Match LFB is used to look up the 282 destination information in a packet and select a next hop index for 283 sending the packet onward. A next hop applicator LFB uses the next 284 hop index metadata to apply the proper headers to the IP packets, and 285 direct them to the proper egress. 287 3.2. Overview of LFB Classes in the Library 289 It is critical to classify functional requirements into various 290 classes of LFBs and construct a typical but also flexible enough base 291 LFB library for various IP forwarding equipments. In the process, 292 some principles may be applied: 294 (1)if a function can be designed by either one LFB or two or more 295 LFBs with the same cost, it will be designed by two or more LFBs so 296 as to provide more flexibility for implementers. 298 (2)when flexibility is not required, an LFB should take advantage of 299 its as much as possible independence and leave least couples with 300 other LFBs. The couples may be from LFB attributes definitions as 301 well as physical implementations. 303 (3)unless there is a difference in actual functionality, it should 304 not represent the same thing in two different fashions. Or else, it 305 may add extra burden on implementation. 307 The document defines groups of LFBs for typical router function 308 requirements: 310 o A group of Ethernet processing LFBs are defined to abstract the 311 packet processing for Ethernet as the port media type. As the 312 most popular media type with rich processing features, Ethernet 313 media processing LFBs also provide typical work for other media 314 types. Definitions for processing of other port media types like 315 POS or ATM may be incorporated in the library in future version of 316 the document. 318 o A group of LFBs are defined for IP packet validation process. 319 Actually, only one LFB is currently defined specifi for individual 320 IPv4 or IPv6 protocol validations. 322 o A group of LFBs are defined to abstract IP forwarding process. A 323 unicast longest prefix match LFB and a followed next hop 324 applicator LFB are applied to IP forwarding process. Forwarding 325 process for IPv4 and IPv6 packets are separated, therefore LFBs 326 specifically for IPv4 and IPv6 are separately defined. 328 o A group of address resolution LFBs are defined for the purpose to 329 abstract the process for address resolution function. Actually, 330 there is only one LFB defined for individual IPv4 or IPv6 address 331 resolution or neighbor discovery. In IPv4 case, the LFB is called 332 ARP LFB and in IPv6 case, the LFB is called ND(neighbor discovery) 333 LFB. 335 o A group of LFBs are defined to abstract the process for redirect 336 operation, i.e., data packet transmission between CE and FEs. A 337 RedirectIn LFB describes the process for CE to inject packets to 338 FE LFB paths, and a RedirectOut LFB abstracts the process for 339 various FE LFBs to send data packets to CE. 341 o A group of LFBs are defined for abstracting some general purpose 342 packet processing. These processing processes are usually general 343 to many processing locations in some FE LFB topology. Currently, 344 two such LFBs are defined, a generic dispatch LFB and a generic 345 scheduler LFB. 347 3.3. Document Structure 349 For every group of LFB classes, a set of LFBs are defined for 350 individual function purposes. Section 6 (LFB Descriptions Section) 351 makes text descriptions in details on individual LFBs. Note that for 352 a complete definition of an LFB, a text description as well as a XML 353 definition is required. 355 Section 8 provides more detailed descriptions on how various typical 356 router functions are implemented based on the defined base LFB 357 classes. 359 To define various LFB classes, a set of base type definitions with 360 the data types, packet frame types, and metadata types have to be 361 specified in advance. Section 5 (Base Types Section) provide a 362 description on the base types used by this LFB library. In order to 363 provide an extensive use of these base types for other LFB 364 definitions, the base type definitions are provided by a specific xml 365 file as a base type library which is separate from the LFB definition 366 library. 368 LFB classes are finally defined by XML with specifications and schema 369 from the ForCES FE model[RFC5812]. Section 6 (LFB Definitions 370 Section) provide the complete XML definitions of the base LFB classes 371 library. 373 4. Base Types 375 The FE model [RFC5812] has specified the following data types as 376 predefined (built-in) atomic data-types: 378 char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], 379 string, byte[N], boolean, octetstring[N], float16, float32, float64. 381 Based on these atomic data types and with the use of type definition 382 elements in the FE model XML schema, new data types, packet frame 383 types, and metadata types can further be defined. 385 To define a base LFB library for typical router functions, a base 386 data types, frame types, and metadata types MUST be defined. This 387 section provides a description of these types and detailed XML 388 definitions for the base types. 390 In order for extensive use of the base type definitions for LFB 391 definitions other than this base LFB library, the base type 392 definitions are provided with a separate xml library file labeled 393 with "BaseTypeLibrary". Users can refer to this library by the 394 statement: 396 398 4.1. Data 400 The following data types are currently defined and put in the base 401 type library: 403 (TBD) 405 4.2. Frame 407 According to FE model [RFC5812], frame types are used in LFB 408 definitions to define the types of frames the LFB expects at its 409 input port(s) and emits at its output port(s). The 410 element in the FE model is used to define a new frame type. 412 The following frame types are currently defined and put in the base 413 type library as base frame types for the LFB library: 415 (TBD) 417 4.3. MetaData 419 LFB Metadata is used to communicate per-packet state from one LFB to 420 another. The element in the FE model is used to define 421 a new metadata type. 423 The following metadata types are currently defined and put in the 424 base type library as base metadata types for the LFB library 425 definitions: 427 (TBD) 429 4.4. XML for Base Type Library 431 434 435 436 EthernetII 437 An Ethernet II frame 438 439 440 ARP 441 an arp packet 442 443 444 IPv4 445 An IPv4 packet 446 447 448 IPv6 449 An IPv6 packet 450 451 452 IPv4Unicast 453 An IPv4 unicast packet 454 455 456 IPv4Multicast 457 An IPv4 multicast packet 458 459 460 IPv6Unicast 461 An IPv6 unicast packet 462 463 464 IPv6Multicast 465 An IPv6 multicast packet 466 467 468 Arbitrary 469 Any kinds of frames 470 471 472 473 474 IPv4Addr 475 IPv4 address 476 byte[4] 477 478 479 IPv6Addr 480 IPv6 address 481 byte[16] 482 483 484 IEEEMAC 485 IEEE mac. 486 byte[6] 487 488 489 LANSpeedType 490 491 Network speed values 492 493 uint32 494 495 496 LAN_SPEED_10M 497 10M Ethernet 498 499 500 LAN_SPEED_100M 501 100M Ethernet 502 503 504 LAN_SPEED_1G 505 1000M Ethernet 506 507 508 LAN_SPEED_10G 509 10G Ethernet 510 511 512 LAN_SPEED_AUTO 513 LAN speed auto 514 515 516 523 524 525 526 DuplexType 527 528 Duplex types 529 530 uint32 531 532 533 Auto 534 Auto negotitation. 535 536 537 Half-duplex 538 port negotitation half duplex 539 540 541 Full-duplex 542 port negotitation full duplex 543 544 545 546 547 548 549 PortStatusValues 550 551 The possible values of status. Used for both 552 administrative and operation status 553 554 555 uchar 556 557 558 Disabled 559 the port is operatively disabled. 561 562 563 UP 564 the port is up. 565 566 567 Down 568 The port is down. 569 570 571 573 574 575 576 PortStatsType 577 Port statistics 578 579 580 InUcastPkts 581 Number of unicast packets received 582 uint64 583 584 585 InMulticastPkts 586 Number of multicast packets received 587 uint64 588 589 590 InBroadcastPkts 591 Number of broadcast packets received 592 uint64 593 594 595 InOctets 596 number of octets received 597 uint64 598 599 600 OutUcastPkts 601 Number of unicast packets transmitted 602 uint64 603 604 605 OutMulticastPkts 606 Number of multicast packets transmitted 607 uint64 608 609 610 OutBroadcastPkts 611 Number of broadcast packets transmitted 612 uint64 613 614 615 OutOcetes 616 Number of octets transmitted 617 uint64 618 619 620 InErrorPkts 621 Number of input error packets 622 uint64 623 624 625 OutErrorPkts 626 Number of output error packets 627 uint64 628 629 630 631 632 633 PHYPortStatsType 634 The content of statistic for EtherPHYCop. 635 636 637 NumPacketsReceived 638 The number of packets received. 639 uint64 640 641 642 NumPacketsTransimtted 643 The number of packets transimtted. 644 uint64 645 646 647 NumPacketsDroped 648 The number of packets droped. 649 uint64 650 651 652 653 654 MACStatsType 655 The content of statistic for EtherPHYCop. 656 contents 658 659 660 EtherDispatchTableType 661 the type of etherDispatch table entry. 662 663 664 LogicalPortID 665 Logical port ID. 666 uint32 667 668 669 EtherType 670 The EtherType value in the Ether head. 671 672 uint32 673 674 675 OutputIndex 676 Group output port index. 677 uint32 678 679 680 681 682 VlanInputTableType 683 VLAN Output table entry type. 684 685 686 IncomingPortID 687 The incoming port ID. 688 uint32 689 690 691 VlanID 692 VLAN ID. 693 uint32 694 695 696 LogicalPortID 697 logical port ID. 698 uint32 699 700 701 702 703 EtherClassifyStatsType 704 VLAN Output table entry type. 705 706 707 EtherType 708 The EtherType value 709 uint32 710 711 712 PacketsNum 713 Packets number 714 uint64 715 716 717 718 719 IPv4ValidatorStatisticsType 720 Statistics type in IPv4validator. 721 722 723 badHeaderPkts 724 Number of bad header packets. 725 uint32 726 727 728 badTotalLengthPkts 729 Number of bad total length packets. 730 uint32 731 732 733 badTTLPkts 734 Number of bad TTL packets. 735 uint32 736 737 738 badChecksum 739 Number of bad checksum packets. 740 uint32 741 742 743 744 745 IPv6ValidatorStatisticsType 746 Statistics type in IPv6validator. 747 748 749 badHeaderPkts 750 Number of bad header packets. 751 uint32 752 753 754 badTotalLengthPkts 755 Number of bad total length packets. 756 uint32 757 758 759 badHopLimitPkts 760 Number of bad Hop limit packets. 761 uint32 762 763 764 765 766 IPv4PrefixTableType 767 Each row of the IPv4 Prefix Table 768 769 770 IPv4Address 771 An IPv4 Address 772 IPv4Addr 773 774 775 Prefixlen 776 The prefix length 777 778 uchar 779 780 781 782 783 784 785 HopSelector 786 HopSelector is the nexthop ID which points to 787 the nexthop table 788 uint32 789 790 791 ECMPFlag 792 An ECMP Flag for this route 793 794 boolean 795 796 797 False 798 This route does not have multiple 799 nexthops. 800 801 802 True 803 This route has multiple nexthops. 804 805 806 807 808 809 810 DefaultRouteFlag 811 A Default Route Flag for supporting loose RPF. 812 813 814 boolean 815 816 817 False 818 This is not a default route. 819 820 821 822 True 823 This route is a default route. for 824 supporting the loose RPF. 825 826 827 828 829 830 831 832 IPv6PrefixTableType 833 Each row of the IPv6 Prefix Table 834 835 836 IPv6Address 837 An IPv6 Address 838 IPv6Addr 839 840 841 Prefixlen 842 The prefix length 843 844 uchar 845 846 847 848 849 850 851 HopSelector 852 HopSelector is the nexthop ID which points 853 to the nexthop table 854 uint32 855 856 857 ECMPFlag 858 An ECMP Flag for this route 859 860 boolean 861 862 863 False 864 This route does not have multiple 865 nexthops. 866 867 868 True 869 This route has multiple nexthops. 870 871 872 873 874 875 876 DefaultRouteFlag 877 A Default Route Flag. 878 879 boolean 880 881 882 False 883 This is not a default route. 884 885 886 887 True 888 This route is a default route. 889 890 891 892 893 894 895 896 897 NexthopOptionType 898 Special Values of NextHopOption Type 899 900 uint8 901 902 903 Normal 904 Normal Forwarding 905 906 907 Local 908 The packet need to be forwarded to locally 909 attached host 910 911 912 913 914 915 IPv4NextHopTableType 916 Each row of the IPv4 NextHop Table 917 918 919 NexthopID 920 ID of the NextHop 921 uint32 922 923 924 OutputLogicalPortID 925 The ID of the Logical OutputPort 926 uint32 927 928 929 MTU 930 Maximum Transmission Unit for out going port. 931 It is for desciding whether the packet need fragmentation 932 933 uint32 934 935 936 NexthopIPAddr 937 Next Hop IPv4 Address 938 IPv4Addr 939 940 941 NexthopOption 942 Next Hop Option 943 NexthopOptionType 944 945 946 EncapOutputIndex 947 Group output port index 948 uint32 949 950 951 952 953 ArpTableType 954 ARP table entry type. 955 956 957 LogicalPortID 958 Logical port ID. 959 uint32 960 961 962 DstIPv4Address 963 Destination IPv4 address. 964 IPv4Addr 965 966 967 DstMac 968 Mac of the Neighbor. 969 IEEEMAC 970 971 972 SrcMac 973 Source MAC. 974 IEEEMAC 975 976 977 978 979 NbrTableType 980 IPv6 neighbour table entry type. 981 982 983 LogicalPortID 984 Logical port ID. 985 uint32 986 987 988 DstIPv6Address 989 Destination IPv4 address. 990 IPv6Addr 991 992 993 DstMac 994 Mac of the Neighbor. 995 IEEEMAC 996 997 998 SrcMac 999 Source MAC. 1000 IEEEMAC 1001 1002 1003 1004 1005 VlanOutputTableType 1006 Vlan Output table entry type. 1007 1008 1009 LogicalPortID 1010 Logical port ID. 1011 uint32 1012 1013 1014 VlanID 1015 VLAN ID. 1016 uint32 1017 1018 1019 OutputLogicalPortID 1020 Output logical port ID. 1021 uint32 1022 1023 1024 1025 1026 Portv4AddressInforType 1027 Port address information, for v4 port. 1028 1029 1030 IPv4Address 1031 IPv4 address 1032 IPv4Addr 1033 1034 1035 IPv4NetMask 1036 IPv4 net mask length 1037 uint32 1038 1039 1040 SrcMAC 1041 Source Mac address 1042 IEEEMAC 1043 1044 1045 1046 1047 Portv4AddrInfoTableType 1048 Logical port (v4) address information table type 1049 1050 1051 1052 LogicalPortID 1053 Logical port id. 1054 uint32 1055 1056 1057 Portv4AddrInfo 1058 1059 1060 Portv4AddressInforType 1061 1062 1063 1064 1065 1066 MetadataDispatchTableType 1067 Metadata dispatch table type. 1068 1069 1070 MetadataID 1071 metadata ID 1072 uint32 1073 1074 1075 MetadataValue 1076 metadata value. 1077 uint32 1078 1079 1080 OutputIndex 1081 group output port index. 1082 uint32 1083 1084 1085 1086 1087 SchdDisciplineType 1088 scheduling discipline type. 1089 1090 uint32 1091 1092 1093 FIFO 1094 First In First Out scheduler. 1095 1096 1097 RR 1098 Round Robin. 1099 1100 1101 1102 1103 1104 QueueDepthType 1105 the Depth of Queue. 1106 1107 1108 QueueID 1109 Queue ID 1110 uint32 1111 1112 1113 QueueDepthInPackets 1114 the Queue Depth when the depth units 1115 are packets. 1116 uint32 1117 1118 1119 QueueDepthInBytes 1120 the Queue Depth when the depth units 1121 are bytes. 1122 uint32 1123 1124 1125 1126 1127 MetaDispatchTableType 1128 Metadata dispatch table type. 1129 1130 1131 metadataID 1132 metadata ID 1133 uint32 1134 1135 1136 MetadataValue 1137 metadata value. 1138 uint32 1139 1140 1141 OutputIndex 1142 group output port index. 1143 uint32 1144 1145 1146 1147 1148 1149 1150 PHYPortID 1151 The physical port ID that a packet has entered. 1152 1153 1 1154 uint32 1155 1156 1157 SrcMAC 1158 Source MAC Address 1159 2 1160 IEEEMAC 1161 1162 1163 DstMAC 1164 Destination MAC Address 1165 3 1166 IEEEMAC 1167 1168 1169 LogicalPortID 1170 ID of logical port. 1171 4 1172 uint32 1173 1174 1175 EtherType 1176 The value of EtherType. 1177 5 1178 uint32 1179 1180 1181 VlanID 1182 Vlan ID. 1183 6 1184 uint32 1185 1186 1187 VlanPriority 1188 The priority of Vlan. 1189 7 1190 uint32 1191 1192 1193 NexthopIPv4Addr 1194 Nexthop IP address. 1195 8 1196 IPv4Addr 1197 1198 1199 NexthopIPv6Addr 1200 Nexthop IP address. 1201 9 1202 IPv6Addr 1203 1204 1205 HopSelector 1206 HopSelector is the nexthop ID which points to the 1207 nexthop table 1208 10 1209 uint32 1210 1211 1212 ExceptionID 1213 1215 Exception Types 1216 11 1217 1218 uint32 1219 1220 1221 Other 1222 Any other exception. 1223 1224 1225 BroadCastPacket 1226 Packet with destination address equal to 1227 255.255.255.255 1228 1229 1230 BadTTL 1231 The packet can't be forwarded as the TTL has 1232 expired. 1233 1234 1235 IPv4HeaderLengthMismatch 1236 IPv4 Packet with header length > 5 1237 1238 1239 LengthMismatch 1240 The packet length reported by link layer is 1241 less than the total length field. 1242 1243 1244 RouterAlertOptions 1245 Packet IP head include Router Alert options. 1246 1247 1248 1249 RouteInTableNotFound 1250 There is no route in the route table 1251 corresponding to the packet destination address 1252 1253 1254 1255 NextHopInvalid 1256 The NexthopID is invalid 1257 1258 1259 FragRequired 1260 The MTU for outgoing interface is less than 1261 the packet size. 1262 1263 1264 LocalDelivery 1265 The packet is for a local interface. 1266 1267 1268 1269 GenerateICMP 1270 ICMP packet needs to be generated. 1271 1272 1273 PrefixIndexInvalid 1274 The prefixIndex is wrong. 1275 1276 1277 ArpTableL2NotFound 1278 Packet can't find the associated L2 1279 information in the Arptable 1280 1281 1282 OutputLogiclPortIDNotFound 1283 Packet can't find OutputLogicalPortID in 1284 VLANOutputTable 1285 1286 1287 IPv6HopLimitZero 1288 Packet with Hop Limit zero 1289 1290 1291 IPv6NextHeaderHBH 1292 Packet with next header set to Hop-by-Hop 1293 1294 1295 1296 1297 1298 1299 OutputLogicalPortID 1300 ID of output logical port. 1301 12 1302 uint32 1303 1304 1305 RedirectIndex 1306 Redirect Output port index. 1307 13 1308 uint32 1309 1310 1311 1313 5. LFB Class Description 1315 According to ForCES specifications, LFB (Logical Function Block) is a 1316 well defined, logically separable functional block that resides in an 1317 FE, and is a functionally accurate abstraction of the FE's processing 1318 capabilities. An LFB Class (or type) is a template that represents a 1319 fine-grained, logically separable aspect of FE processing. Most LFBs 1320 are related to packet processing in the data path. LFB classes are 1321 the basic building blocks of the FE model. Note that RFC 5810 has 1322 already defined an 'FE Protocol LFB' that is defined as a logical 1323 entity in each FE to control the ForCES protocol. RFC 5812 has 1324 already defined an 'FE Object LFB' that is defined to make the FE 1325 information easily accessible to CE. Information like the FE Name, 1326 FE ID, FE State, LFB Topology in the FE are represented in this LFB. 1328 As mentioned in section 3, this document intends to provide a base 1329 LFB library for implementing typical router functions, especially for 1330 IP forwarding functions. As a result, LFB classes defined here are 1331 base LFBs to implement router forwarding. 1333 5.1. Ethernet Processing LFBs 1335 As the most popular physical and data link layer protocols, Ethernets 1336 are widely deployed. It becomes a basic requirement for a router to 1337 be able to process various Ethernet data packets. 1339 Note that there exist different versions of Ethernet protocols, like 1340 Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. 1341 There also exist varieties of LAN techniques based on Ethernet, like 1342 various VLANs, MACinMAC, etc. Ethernet processing LFBs defined here 1343 are intended to be able to cope with all these variations of Ethernet 1344 technology. 1346 There are also various types of Ethernet physical interface media. 1347 Among them, copper and fiber media may be the most popular ones. As 1348 a base LFB definition and a start work, the document only defines an 1349 Ethernet physical LFB with copper media. For other media interfaces, 1350 specific LFBs may be defined in the future versions of the library. 1352 5.1.1. EtherPHYCop 1354 EtherPHYCop LFB abstracts an Ethernet interface at its physical 1355 layer. It limits the physical media to copper. 1357 The LFB is defined with one singleton input. The input data of the 1358 LFB are expected to be Ethernet packets. Note that Ethernet packets 1359 here cover all packets encapsulated with different versions of 1360 Ethernet protocols, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, 1361 IEEE 802.3/802.2 SNAP. It also includes packets encapsulated with 1362 varieties of LAN techniques based on Ethernet, like various VLANs, 1363 MACinMAC, etc. As a result, we define various Ethernet frames as a 1364 frame name called 'EthernetAll'. In an LFB abstracted processing 1365 path in an FE, usually the Ethernet packets are from an upstream LFB 1366 like an EtherMACOut LFB. It is not expected that an input Ethernet 1367 packet be associated with some metadata. After the LFB receives the 1368 Ethernet packets, it will further process the packets at physical 1369 layer and eventually put them on the physical media wire for 1370 transmission. Note that the media wire transmission process in the 1371 LFB is abstracted as a default function of the LFB rather than an 1372 input or output interface of the LFB. 1374 The LFB is also defined with one singleton output. The output data 1375 produced are also with 'EthernetAll' frame type. Every output data 1376 packet is associated with a 'PHYPortID' metadata to indicate later 1377 processing LFBs of which physical port the packet is from. Note that 1378 all the data packets are originated from media wire inside the LFB, 1379 which is defined as a default function of the LFB. As a physical 1380 layer abstraction module, the LFB does not possess the ability to 1381 specify encapsulations of types of Ethernet, rather, it produces 1382 various Ethernet types just according to what it receives from 1383 Ethernet media wire. In an LFB-based processing path topology, 1384 packets output from the EtherPHYCop lFB will usually go to an LFB 1385 like EtherMACIn LFB for further Ethernet processing. 1387 Note that as a base definition, functions like multiple virtual 1388 physical layers are not supported in this LFB version. It may be 1389 supported in the future by defining a subclass or a new version of 1390 this LFB. 1392 Several components are defined for the LFB. 1394 AdminStatus is defined for CE to administratively manage the status 1395 of the LFB. Via the component, CE may startup or shutdown the LFB. 1396 The default status is set to 'Down'. Note that as a physical layer 1397 LFB for whole Ethernet processing, the administrative status 1398 configuration of this LFB will simultaneously affect status of 1399 related Ethernet processing LFBs. An 'Up' or 'Down' of the LFB 1400 actually mean the whole Ethernet interface 'Up' or 'Down' with all 1401 the Ethernet processing ability. To meet this, A OperStatus 1402 component is defined in all Ethernet related processing LFBs like 1403 EtherMACIn, EtherClassifier, EtherEncap, and EtherMACOut LFBs to 1404 reflect the physical layer administrative status. A 1405 PHYPortStatusChanged event is defined for the LFB to report to CE 1406 whenever there is a port status change during operation. 1408 PHYPortID component is defined for CE to assign an ID to the physical 1409 port. The component will be used to produce a metadata associated 1410 with every Ethernet packet the LFB receives from media and is going 1411 to hand to later LFBs for further processing. 1413 A group of components are defined for link speed management. The 1414 AdminLinkSpeed is for CE to configure proper link speed for the port 1415 and the OperLinkSpeed is for CE to query the actual link speed in 1416 operation. The default value for the AdminLinkSpeed is set to auto- 1417 negotiation mode. A SupportedLinkSpeed capability attribute is also 1418 defined for CE to query the link speed ability. A LinkSpeedChanged 1419 event is defined for the LFB to report to CE whenever there is a link 1420 speed change during operation. 1422 A group of components are defined for duplex mode management. The 1423 AdminDuplexMode is for CE to configure proper duplex mode for the 1424 port and the OperDuplexMode is for CE to query the actual duplex mode 1425 in operation. The default value for the AdminDuplexMode is set to 1426 auto-negotiation mode. A SupportedDuplexMode capability is also 1427 defined for CE to query the port duplex mode ability. 1429 There are also some other components, capabilities, events defined in 1430 the LFB for various purposes. See section 6 for detailed XML 1431 definitions of the LFB. 1433 5.1.2. EtherMACIn 1435 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. It 1436 specifically describes Ethernet processing functions like MAC address 1437 locality check, deciding if the Ethernet packets should be bridged, 1438 provide Ethernet layer flow control, etc. 1440 The LFB is defined with one singleton input. The input is expected 1441 to receive all types of Ethernet packets which are usually output 1442 from some Ethernet physical abstraction layer LFB, like an 1443 EtherPHYCop LFB. Every input packet is associated with a metadatum 1444 indicating the physical port ID that the packet comes. 1446 Input Ethernet packets will usually be checked for locality. A 1447 LocalMACAddresses component is defined for the LFB so that CE is able 1448 to configure one or more Ethernet MAC addresses to the LFB for the 1449 use of locality check. All packets that do not pass through the 1450 locality check will be dropped in the LFB. A PromiscuousMode 1451 component in the LFB is further defined to decide if the LFB should 1452 work in a promiscuous mode. In this mode, the LFB will not do the 1453 locality check and all Ethernet packets will pass through the LFB 1454 without being dropped. 1456 The LFB is defined with two separate singleton outputs. All Output 1457 packets are in Ethernet format, possibly with various Ethernet types. 1458 One singleton output is called NormalPathOut. It usually outputs 1459 Ethernet packets to some LFB like an EtherClassifier LFB for further 1460 L3 forwarding process. Metadata associated with every packet from 1461 this output is PHYPortID, which keeps indicating which physical port 1462 the packet is from. 1464 Another singleton output is called L2BridgingPathOut. Although this 1465 LFB library is basically defined to meet typical router functions, it 1466 is with natural requirement that the definitions here should provide 1467 reasonable compatibility considerations for future wider use. The 1468 L2BridgingPathOut is defined to meet the requirement that L2 bridging 1469 functions may be optionally supported simultaneously with L3 1470 processing and Some L2 bridging LFBs may be defined in the future. A 1471 Boolean flag component called L2BridgingPathEnable is defined to make 1472 the L2 bridging output as optional. An FE that does not support 1473 bridging will internally set this flag to false, and additionally 1474 sets the flag property as read-only. In this case CE then can read 1475 the flag to know that the FE does not support bridging function and 1476 the L2 bridging output is always disabled. An FE that supports L2 1477 bridging will internally set the flag property as read-write. In 1478 this case, CE then can choose to enable or disable the 1479 L2BridgingPathOut output by setting this flag as desired. If the 1480 flag is set to true, by also instantiating some L2 bridging LFB 1481 instances following the L2BridgingPathOut, FE are expected to fulfill 1482 L2 bridging functions. Whereas, in this case, the default value for 1483 the flag is defined as false, meaning L2 bridging output is closed by 1484 default. Note that, when enabled, l2BridgingPathOut will output 1485 packets exactly the same as that in the NormalPathOut 1486 output(Editorial note: need more discussions here on if the L2 output 1487 is the same as normal output). The metadata associated with every 1488 packet is also PHYPortID. 1490 Ethernet layer flow control is usually implemented cooperatively by 1491 EtherMACIn LFB and EtherMACOut LFB. How the flow control is 1492 implemented is vendor-specific. As an abstraction, this LFB defines 1493 two flag components for CE to enable or disable the flow control 1494 functions. The flow control is further distinguished by Tx flow 1495 control and Rx flow control, separately for sending process and 1496 receiving process flow controls. A TxFlowControl flag and a 1497 RxFlowControl flag are then separately defined. In order for 1498 EtherMACOut LFB able to cooperatively work for flow control, the 1499 flags are also referenced in the EtherMACOut LFB as aliases in this 1500 LFB. 1502 An OperStatus component is also defined in the LFB for CE to read 1503 operation status of the LFB. Note that the status will be 1504 administratively managed via AdminStatus in the physical port LFB 1505 that the LFB usually rely on. /*how to describe the relationship 1506 between the adminstatus and the operstatus is still a problem */ 1508 Note that as a base definition, functions like multiple virtual MAC 1509 layers are not supported in this LFB version. It may be supported in 1510 the future by defining a subclass or a new version of this LFB. 1512 There are also some other components, capabilities, events defined in 1513 the LFB for various purposes. See section 6 for detailed XML 1514 definitions of the LFB. 1516 5.1.3. EtherClassifier 1518 EtherClassifier LFB abstracts the process to decapsulate Ethernet 1519 packets and classify the data packets into various network layer data 1520 packets according to information included in the Ethernet packets 1521 headers. 1523 Input of the LFB expects all types of Ethernet packets, including 1524 VLAN Ethernet types. The input is a singleton input which may 1525 connect to an upstream LFB like EtherMACIn LFB. The input is also 1526 capable of multiplexing to allow for multiple upstream LFBs being 1527 connected. For instance, when L2 bridging function is enabled in 1528 EtherMACIn LFB, some L2 bridging LFBs may be applied. In this case, 1529 some Ethernet packets after L2 processing may have to be input to 1530 EtherClassifier LFB for classification, while simultaneously packets 1531 directly output from EtherMACIn may also need to input to this LFB. 1532 Input of this LFB is capable of handling this case. Usually, every 1533 input Ethernet packet is expected to be associated with a PHYPortID 1534 metadatum, indicating the physical port the packet comes from. In 1535 some cases, for instance, like in an MACinMAC case, a LogicalPortID 1536 metadatum may be expected to associate with the Ethernet packet to 1537 further indicate which logical port the Ethernet packet belongs to. 1538 Note that PHYPortID metadata is always expected while LogicalPortID 1539 metadata is optionally expected. 1541 A VLANInputTable component is defined in the LFB to classify VLAN 1542 Ethernet packets. According to IEEE VLAN specifications, all 1543 Ethernet packets can be recognized as VLAN types by defining that if 1544 there is no VLAN encapsulation in a packet, a case with VLAN tag 0 is 1545 considered. Therefore the table actually applies to every input 1546 packet of the LFB. The table assigns every input packet with a new 1547 LogicalPortID according to the packet incoming port ID and the VLAN 1548 ID. A packet incoming port ID is defined as a physical port ID if 1549 there is no logical port ID associated with the packet, or a logical 1550 port ID if there is a logical port ID associated with the packet. 1551 The VLAN ID is exactly the Vlan ID in the packet if it is a VLAN 1552 packet, or 0 if it is not a VLAN packet. Note that a logical port ID 1553 of a packet may be rewritten with a new one by the VLANInputTable 1554 processing. 1556 An EtherDispatchTable component is defined to dispatch every Ethernet 1557 packet to a group of outputs according to the logical port ID 1558 assigned by VLANInputTable to the packet and the Ethernet type in the 1559 Ethernet packet header. By CE configuring the dispatch table, the 1560 LFB can be expected to classify various network layer protocol type 1561 packets and make them output at different output port. It is then 1562 easily expected that the LFB classify packets according to protocols 1563 like IPv4, IPv6, MPLS, ARP, ND, etc. 1565 Output of the LFB is hence defined as a group output. Because there 1566 may be various types of protocol packets at the output ports, the 1567 frameproduced is defined as arbitrary for the purpose of wide 1568 extensibility in the future. In order for downstream LFBs to use, a 1569 bunch of metadata is produced to associate with every output packet. 1570 The medatdata contain normal information like PHYPortID. It also 1571 contains information on Ethernet type, source MAC address, and 1572 destination MAC address of its original Ethernet packet. Moreover, 1573 it contains information of logical port ID assigned by this LFB. 1574 This metadata may be used by downstream LFBs for packet processing. 1575 Lastly, it may conditionally contain information like VlanID and 1576 VlanPriority with the condition that the packet is a VLAN packet. 1578 A MaxOutPutPorts is defined as the capability of the LFB to indicate 1579 how many classification output ports the LFB is capable. 1580 /*discussion*/ 1582 Note that logical port ID and physical port ID mentioned above are 1583 all originally configured by CE, and are globally effective within an 1584 ForCES NE (Network Element). To distinguish a physical port ID from 1585 a logical port ID in the incoming port ID field of the 1586 VLANInputTable, physical port ID and logical port ID must be assigned 1587 with separate number spaces. /*discussion */ 1589 There are also some other components, capabilities, events defined in 1590 the LFB for various purposes. See section 6 for detailed XML 1591 definitions of the LFB. 1593 5.1.4. EtherEncapsulator 1595 EtherEncapsulator LFB abstracts the process to encapsulate IP packets 1596 to Ethernet packets. 1598 Input of the LFB expects types of IP packets, including IPv4 and IPv6 1599 types. The input is a singleton one which may connect to an upstream 1600 LFB like an IPv4NextHopApplicator, an IPv6NextHopApplicator, or any 1601 LFB which requires to output packets for Ethernet encapsulation. The 1602 input is capable of multiplexing to allow for multiple upstream LFBs 1603 being connected. For instance, an IPv4NextHopApplicator or an 1604 IPv6NextHopApplicator may concurrently exist, and some L2 bridging 1605 LFBs may also output packets to this LFB simultaneously. Input of 1606 this LFB is capable of handling this case. Usually, every input 1607 Ethernet packet is expected to be associated with an output logical 1608 port ID and a next hop IP address as its metadata. In the case when 1609 L2 bridging function is implemented, an input packet may also 1610 optionally receive a VLAN priority as its metadata. In this case, 1611 default value for this metadata is set to 0. 1613 There are several outputs for this LFB. One singleton output is for 1614 normal success packet output. Packets which have found Ethernet L2 1615 information and have been successfully encapsulated to an Ethernet 1616 packet will output from this port to downstream LFB. Note that this 1617 LFB specifies to use Ethernet II as its Ethernet encapsulation type. 1618 Success output also produces an output logical port ID as metadatum 1619 of every output packet for a downstream LFB to decide which logical 1620 port the packet should go out. The downstream LFB usually dispatches 1621 the packets based on its associated output logical port ID. Hence, a 1622 generic dispatch LFB as defined in Section 5.6.1 may be adopted for 1623 dispatching packets based on output logical port ID. 1625 Note that in some implementations of LFBs topology, the processing to 1626 dispatch packets based on an output logical port ID may also take 1627 place before an Ethernet encapsulation,i.e., packets coming into the 1628 encapsulator LFB have already been switched to individual logical 1629 output port paths. In this case, the EtherEncap LFB success output 1630 may be directly connected to a downstream LFB like an EtherMACOut 1631 LFB. 1633 Another singleton output is for IPv4 packets that are unfortunately 1634 unable to find Ethernet L2 encapsulation information by ARP table in 1635 the LFB. In this case, a copy of the packets may need to be 1636 redirected to an ARP LFB in the FE, or to CE if ARP function is 1637 implemented by CE. More importantly, a next hop IP address metadata 1638 should be associated with every packet output here. When an ARP LFB 1639 or CE receives these packets and associated next hop IP address 1640 metadata, it may be expected to generate ARP protocol messages based 1641 on these packets next hop IP addresses to try to get L2 information 1642 for these packets. Refreshed L2 information is then able to be added 1643 in ARP table in this encapsulator LFB by ARP LFB or by CE. As a 1644 result, these packets are then able to successfully find L2 1645 information and be encapsulated to Ethernet packets, and output via 1646 the normal success output to downstream LFB. (Editorial note1: may 1647 need discussion on what more metadata this output packets need? Note 1648 that the packets may be redirected to CE and CE should know what the 1649 purpose of the packets for. A metadata may need to indicate this. 1650 Editorial note2: we may adopt another way to address the case of 1651 packets unable to do ARP. The packets may be redirected to ARP LFB 1652 or CE without keeping a copy of them in this encapsulator LFB. We 1653 expect that after ARP LFB or CE have processed ARP requests based on 1654 the packets, the packets will be redirected back from ARP LFB or CE 1655 to this encapsulator LFB for Ethernet encapsulation. At this time, 1656 it is hoped the ARP table has been refreshed with new L2 information 1657 that will make these packets able to find) 1659 A more singleton output is for IPv6 packets that are unfortunately 1660 unable to find Ethernet L2 encapsulation information by Neighbor 1661 table in the LFB. In this case, a copy of the packets may need to be 1662 redirected to an ND LFB in the FE, or to CE if IPv6 Neighbor 1663 discovery function is implemented by CE. More importantly, a next 1664 hop IP address metadata should be associated with every packet output 1665 here. When the ND LFB or CE receives these packets and associated 1666 next hop IP address metadata, it may be expected to generate neighbor 1667 discovery protocol messages based on these packets next hop IP 1668 addresses to try to get L2 information for these packets. Refreshed 1669 L2 information is then able to be added in neighbor table in this LFB 1670 by ND LFB or by CE. As a result, these packets are then able to 1671 successfully find L2 information and be encapsulated to Ethernet 1672 packets, and output via the normal success output to downstream 1673 LFB.(Editorial note: may need discussion on what more metadata this 1674 output packets need? Note that the packets may be redirected to CE 1675 and CE should know what the purpose of the packets for. A metadata 1676 may need to indicate this) 1678 A singleton output is specifically defined for exception packets 1679 output. All packets that are abnormal during the operations in this 1680 LFB are output via this port. Currently, only one abnormal case is 1681 defined, that is, packets can not find proper information in a VLAN 1682 output table. 1684 The VLAN output table is defined as the component of the LFB. The 1685 table uses a logical port ID as an index to find a VLAN ID and a new 1686 output logical port ID. In reality, the logical port ID applied here 1687 is the output logical port ID received from every input packet in its 1688 associated metadata. According to IEEE VLAN specifications, all 1689 Ethernet packets can be recognized as VLAN types by defining that if 1690 there is no VLAN encapsulation in a packet, a case with VLAN tag 0 is 1691 considered. Therefore, every input IP packet actually has to look up 1692 the VLAN output table to find out a VLAN ID and a new output logical 1693 port ID according to its original logical port ID. 1695 The ARP table in the LFB is defined as a component of the LFB. The 1696 table is for IPv4 packet to find its next hop Ethernet layer MAC 1697 addresses. Input IPv4 packet will use an output logical port ID 1698 which is got by looking up the VLAN output table, and a next hop IPv4 1699 address which is got by upstream next hop applicator LFB, to look up 1700 the ARP table to find the Ethernet L2 information, i.e., the source 1701 MAC address and destination MAC address. 1703 The neighbor table is defined as another component of the LFB. The 1704 table is for IPv6 packet to find its next hop Ethernet layer MAC 1705 addresses. Like the ARP table, input IPv6 packet will use its output 1706 logical port ID got from looking up the VLAN output table, and the 1707 packet next hop IPv4 address got by upstream next hop applicator LFB, 1708 to look up the neighbor table to find the Ethernet source MAC address 1709 and destination MAC address. 1711 As will be described in the address resolution LFBs section (section 1712 5.4), Layer 2 address resolution protocols may be implemented with 1713 two choices. One is by FE with specific address resolution LFB, like 1714 an ARP LFB or an ND LFB. The other is to redirect address resolution 1715 protocol messages to CE for CE to implement the function. 1717 As described in section 5.4, the ARP LFB defines the ARP table in 1718 this encapsulator LFB as its alias, and the ND LFB defines the 1719 neighbor table as its alias. This means that the ARP table or the 1720 neighbor table will be maintained or refreshed by the ARP LFB or the 1721 ND LFB when the LFBs are used. 1723 Note that the ARP table and the neighbor table defined in this LFB 1724 are all with property of read-write. CE can also configure the 1725 tables by ForCES protocol [RFC5810]. This makes possible that IPv4 1726 ARP protocol or IPv6 Neighbor Discovery protocol may be implemented 1727 at CE side,i.e., after CE manages an ARP or Neighbor discovery 1728 protocol and gets address resolution results, CE can configure them 1729 to an ARP or neighbor table in FE. 1731 With all the information got from VLAN table and ARP or Neighbor 1732 table, input IPv4 or IPv6 packets are then able to be encapsulated to 1733 Ethernet layer packets. Note that according to IEEE 802.1Q, if input 1734 packets are with non-zero VLAN priority metadata, the packets will 1735 always be encapsulated with a VLAN tag, no matter the value of VLAN 1736 ID is zero or not. If the VLAN priority and the VLAN ID are all 1737 zero, the packets will be encapsulated without a VLAN tag. 1738 Successfully encapsulated packets are then output via success output 1739 port. 1741 There are also some other components, capabilities, events defined in 1742 the LFB for various purposes. See section 6 for detailed XML 1743 definitions of the LFB. 1745 5.1.5. EtherMACOut 1747 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. 1748 It specifically describes Ethernet packet output process. Ethernet 1749 output functions are closely related to Ethernet input functions, 1750 therefore many components defined in this LFB are actually alias of 1751 EtherMACIn LFB. 1753 The LFB is defined with one singleton input(Editorial note: do we 1754 need another input for L2 bridging input?). The input is expected to 1755 receive all types of Ethernet packets which are usually output from 1756 some Ethernet encapsulation LFB. Every input packet is associated 1757 with a metadatum indicating the physical port ID that the packet will 1758 go(Editorial note: Ethernet encapsulation LFB actually generate 1759 logical port ID metadata, how has it been changed to physical port 1760 ID?). 1762 The LFB is defined with a singleton output. All Output packets are 1763 in Ethernet format, possibly with various Ethernet types. Downstream 1764 LFB the output links to is usually Ethernet physical LFBs like 1765 EtherPHYcop LFB. Metadata associated with every packet from this 1766 output is PHYPortID, which keeps indicating which physical port the 1767 packet is to. 1769 Ethernet layer flow control is usually implemented cooperatively by 1770 EtherMACIn LFB and EtherMACOut LFB. How the flow control is 1771 implemented is vendor-specific. As an abstraction, this LFB defines 1772 two flag components for CE to enable or disable the flow control 1773 functions, a TxFlowControl flag and a RxFlowControl flag, and they 1774 are all defined as aliases of EtherMACIn LFB. 1776 An OperStatus component is also defined in the LFB as an alias of 1777 EtherMACIn LFB, so as for CE to read operation status of the LFB. 1779 Note that as a base definition, functions like multiple virtual MAC 1780 layers are not supported in this LFB version. It may be supported in 1781 the future by defining a subclass or a new version of this LFB. 1783 There are also some other components, capabilities, events defined in 1784 the LFB for various purposes. See section 6 for detailed XML 1785 definitions of the LFB. 1787 5.2. IP Packet Validation LFBs 1789 An LFB is defined to abstract IP packet validation process. An 1790 IPv4Validator LFB is specifically for IPv4 protocol validation and an 1791 IPv6Validator LFB for IPv6. 1793 5.2.1. IPv4Validator 1795 This LFB performs IPv4 packets validation according to RFC 1812 and 1796 RFC 2644. 1798 Input of the LFB always expects packets which have been indicated as 1799 IPv4 packets by an upstream LFB, like an EtherClassifier LFB. There 1800 is no specific metadata expected by the input of the validator LFB. 1802 Note that, as a default provision of RFC 5812, in FE model, all 1803 metadata produced by upstream LFBs will pass through all downstream 1804 LFBs by default without being specified by input port or output port. 1805 Only those metadata that will be used(consumed) by an LFB will be 1806 explicitly marked in input of the LFB as expected metadata. For 1807 instance, in this LFB, even there is no specific metadata expected, 1808 metadata like PHYPortID produced by some upstreaming PHY LFBs will 1809 always pass through this LFB. In some cases, if some component in 1810 the LFB may use the metadata, it actually still can use it regardless 1811 of whether the metadata has been expected or not. 1813 Four output ports are defined to output various validation results. 1814 All validated IPv4 unicast packets will be output at the singleton 1815 IPv4UnicastOut port. All validated IPv4 multicast packets will be 1816 output at the singleton IPv4MulticastOut port. There is no metadata 1817 specifically required to be produced at these output ports. 1819 A singleton ExceptionOut port is defined to output packets which have 1820 been validated as exceptional packets. An exception ID metadata is 1821 produced to indicate which causes it exceptional. Currently defined 1822 exception types include cases like, packet with destination address 1823 equal to 255.255.255.255, Packet with expired TTL, Packet with header 1824 length more than 5 words, and packet IP head including Router Alert 1825 options, etc. Note that even TTL is checked for validity here, 1826 actual operation like decrease of TTL will not be made here, rather 1827 made by followed forwarding LFB. 1829 A singleton output is defined for all packets which have failed the 1830 packet validation. A validate error ID is associated to every failed 1831 packet to indicate the reasons like an invalid packet size, wrong IP 1832 protocol version, wrong checksum, etc. 1834 There are also some other components defined in the LFB for various 1835 purposes. See section 6 for detailed XML definitions of the LFB. 1837 5.2.2. IPv6Validator 1839 This LFB performs IPv6 packets validation according to RFC 2460 and 1840 RFC 4291. 1842 Input of the LFB always expects packets which have been indicated as 1843 IPv6 packets by an upstream LFB like an EtherClassifier LFB. There 1844 is no specific metadata expected by the input of the validator LFB. 1846 Similar to IPv4 validator LFB, IPv6Validator LFB has also defined 1847 four output ports to output various validation results. All 1848 validated IPv6 unicast packets will be output at the singleton 1849 IPv6UnicastOut port. All validated IPv6 multicast packets will be 1850 output at the singleton IPv6MulticastOut port. There is no metadata 1851 specifically required to be produced at these output ports. A 1852 singleton ExceptionOut port is defined to output packets which have 1853 been validated as exceptional packets. An exception ID is produced 1854 to indicate which causes it exceptional. Currently, exception types 1855 include the following cases: 1857 a packet with hop limit to zero 1859 a packet with a link-local destination address. 1861 a packet with a link-local source address. 1863 a packet with destination all-routers. 1865 a packet with destination all-nodes. 1867 a packet with next header set to Hop-by-Hop. 1869 A singleton output is defined for packets which have failed the 1870 packet validation. A validate error ID is associated to every failed 1871 packet to indicate the reasons for the failures. The reasons may 1872 include an invalid packet size, wrong IPv6 protocol version, wrong 1873 source or destination IPv6 addresses, etc. 1875 There are also some other components defined in the LFB for various 1876 purposes. See section 6 for detailed XML definitions of the LFB. 1878 5.3. IP Forwarding LFBs 1880 IP Forwarding LFBs are specifically defined to abstract the IP 1881 forwarding processes. As definitions for a base LFB library, this 1882 document restricts its LFB definition scope for IP forwarding jobs 1883 only to IP unicast forwarding. LFBs for jobs like IP multicast may 1884 be defined in future versions of the document. 1886 A typical IP unicast forwarding job is usually realized by looking up 1887 some forwarding information table to find some next hop information, 1888 and then based on the next hop information, forwarding packets to 1889 specific output ports. It usually takes two steps to do so, firstly 1890 to look up a forwarding information table by means of Longest Prefix 1891 Matching(LPM) rule to find a next hop index, then to use the index to 1892 look up a next hop information table to find enough information to 1893 submit packets to output ports. This document abstracts the 1894 forwarding processes mainly based on the two steps model. However, 1895 there actually exists other models, like one which may only have a 1896 forwarding information base that have conjoined next hop information 1897 together with forwarding information. In this case, if ForCES 1898 technology is to be applied, some translation work will have to be 1899 done in FE to translate attributes defined by this document into real 1900 attributes the implementation has actually applied. 1902 Based on the IP forwarding abstraction, two kind of typical IP 1903 unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next 1904 hop application LFB. They are further distinguished by IPv4 and IPv6 1905 protocols. 1907 5.3.1. IPv4UcastLPM 1909 The LFB abstracts the process for IPv4 unicast LPM table looking up. 1911 Input of the LFB always expects to receive IPv4 unicast packets. An 1912 IPv4 prefix table is defined as a component for the LFB to provide 1913 forwarding information for every input packet. The destination IPv4 1914 address of every packet is as the index to look up the table with the 1915 rule of longest prefix matching(LPM). A hop selector is the matching 1916 result, which will be output to downstream LFBs as an index for next 1917 hop information. 1919 Normal output of the LFB is a singleton output, which will output 1920 IPv4 unicast packet that has passed the LPM lookup and got a hop 1921 selector as the lookup result. The hop selector is associated with 1922 the packet as a metadatum. Followed the normal output of the LPM LFB 1923 is usually a next hop applicator LFB. The LFB receives packets with 1924 their next hop IDs and based on the next hop IDs to forward the 1925 packets. A hop selector associated with every packet from the normal 1926 output will directly act as a next hop ID for a next hop applicator 1927 LFB. 1929 The LFB is defined to provide some facilities to support users to 1930 implement equal-cost multi-path routing (ECMP) or reverse path 1931 forwarding (RPF). However, this LFB itself does not provide ECMP or 1932 RPF. To implement ECMP or RPF, additional specific LFBs, like a 1933 specific ECMP LFB, will have to be defined. This work may be done in 1934 the future version of the document. 1936 For the LFB to support ECMP, an ECMP flag is defined in the prefix 1937 table entries. When the flag is set to true, it indicates this table 1938 entry is for ECMP only. In this case, the hop selector in this table 1939 entry will be used as an index for a downstream specific ECMP LFB to 1940 find its correspondent next hop IDs. When ECMP is applied, it will 1941 usually get multiple next hops information. 1943 To distinguish normal output from ECMP case output, a specific ECMP 1944 output is defined. A packet, which has passed through prefix table 1945 entry lookup with true ECMP flag, will always output from this port, 1946 with the hop selector being its lookup result. The output will 1947 usually directly go to a downstream ECMP processing LFB. In the ECMP 1948 LFB, based on the hop selector, multiple next hop IDs may be found, 1949 and more ECMP algorithms may be applied to optimize the route. As 1950 the result of the ECMP LFB, it will output optimized one or multiple 1951 next hop IDs to its downstream LFB that is usually a next hop 1952 applicator LFB. 1954 For the LFB to support RPF, a default route flag is defined in the 1955 prefix table entry. When set true, the prefix entry is identified as 1956 a default route, and also as a forbidden route for RPF. To implement 1957 various RPF, one or more specific LFBs have to be defined. This job 1958 may be done for the future version of the library. 1960 An exception output is defined to allow some exceptional packets to 1961 output here. Exceptions include cases like packets can not find any 1962 routes by the prefix table. 1964 There are also some other components defined in the LFB for various 1965 purposes. See section 6 for detailed XML definitions of the LFB. 1967 5.3.2. IPv4NextHopApplicator 1969 This LFB abstracts the process of next hop information application to 1970 IPv4 packets. 1972 The LFB receives an IPv4 packet with an associated next hop ID, and 1973 uses the ID to look up a next hop table to find an appropriate output 1974 port from the LFB. Simultaneously, the LFB also implements TTL 1975 operation and checksum recalculation of every IPv4 packet received. 1977 Input of the LFB is a singleton one which expects to receive IPv4 1978 unicast packets and hop selector metadata from an upstream LFB. 1979 Usually, the upstream LFB is directly an IPv4UnicastLPM LFB. While 1980 it is possible some other upstream LFB may be applied. For instance, 1981 when ECMP is supported, the upstream LFB may be some specific ECMP 1982 LFB. 1984 The next hop ID in hop selector metadata of a packet is then used as 1985 an index to look up a next hop table defined in the LFB. Via this 1986 table and the next hop index, important information for forwarding 1987 the packet is found. The information includes: 1989 output logical port ID, which will be used by downstream LFBs to 1990 find proper output port. 1992 next hop option, which decides if the packet should be locally 1993 processed or not. For packets that will be redirected to CE for 1994 processing or that need FE local processing, next hop option will 1995 be marked as 'forwarded to locally attached host' . Packets that 1996 will be normally forwarded will be marked as 'normal forwarding'. 1998 next hop IP address, which will be used by downstream LFB to find 1999 proper output port IP address for this packet. 2001 encapsulation output index, which is used by the packet to find 2002 proper output of this LFB. 2004 There are two output ports. One is for success output and another is 2005 for exception output. Success output is a group output, with an 2006 index to indicate which output instance in the group is adopted. The 2007 index is the encapsulation output index described above. Downstream 2008 LFBs connected to the success output group may be various LFBs for 2009 encapsulation like LFBs for Ethernet encapsulation and for PPP 2010 encapsulation, various LFBs for local processing, and LFBs for 2011 redirecting packets to CE for processing. Next hop table uses the 2012 encapsulation output index to indicate which port instance in the 2013 output group a packet should go. 2015 Every port instance of the success output group will produce metadata 2016 of output logical port ID and next hop IP address for every output 2017 packet. These metadata will be used by downstream LFBs to further 2018 implementing forwarding process. 2020 Note that for next hop option marked as local host processing, the 2021 next hop IP address for the packet is exactly the destination IP 2022 address of the packet. 2024 The exception output of the LFB is a singleton output. It outputs 2025 packets with exceptional cases. An exception ID further indicates 2026 the exception reasons. Exception may happen when a hop selector is 2027 found invalid, or ICMP packets need to be generated (Editorial note: 2028 more discussions here), etc. The exception ID is also produced as a 2029 metadata by the output to be transmitted to a downstream LFB. 2031 There are also some other components defined in the LFB for various 2032 purposes. See section 6 for detailed XML definitions of the LFB. 2034 5.3.3. IPv6UcastLPM 2036 The LFB abstracts the process for IPv6 unicast LPM table looking up. 2038 Definitions of this IPv6UcastLPM LFB is very identical to 2039 IPv4UcastLPM LFB except that all IP addresses related are changed 2040 from IPv4 addresses to IPv6 addresses. See section 6 for detailed 2041 XML definitions of this LFB. 2043 5.3.4. IPv6NextHopApplicator 2045 This LFB abstracts the process of next hop information application to 2046 IPv6 packets. 2048 Definitions of this IPv6NextHopApplicator LFB is very identical to 2049 IPv4NextHopApplicator LFB except that all IP addresses related are 2050 changed from IPv4 addresses to IPv6 addresses. See section 6 for 2051 detailed XML definitions of this LFB. 2053 5.4. Address Resolution LFBs 2055 The address resolution LFBs abstracts the process for address 2056 resolution functions. In the process, address resolution protocols, 2057 like ARP protocol for IPv4 and neighbor discovery protocol for IPv6, 2058 are applied. 2060 There exist two schema under ForCES architecture to implement address 2061 resolution function. One is for FE to implement the address 2062 resolution by use of address resolution LFBs as defined in this 2063 section. The other is to offload the address resolution from FE to 2064 CE. In this case, address resolution LFBs will not be used. All 2065 address resolution protocol messages FE has received will be 2066 redirected to CE via ForCES protocol [RFC5810]. CE is responsible to 2067 process the protocol messages and generate new address resolution 2068 messages to send to outer network via FE using ForCES prococol 2069 [RFC5810]. CE will also use ForCES protocol to manage the address 2070 resolution tables, like the ARP table and the neighbor table, in 2071 Ethernet encapsulator LFB. 2073 According to address resolution individually for IPv4 or IPv6 2074 packets, an ARP LFB and an ND(neighbor discovery) LFB are defined as 2075 below. 2077 5.4.1. ARP 2079 The ARP LFB provides the function of address resolution for IPv4 2080 nodes. Two singleton inputs are defined for the LFB. One is for ARP 2081 protocol packet input. The packets are usually come from upstream 2082 LFBs like an Ethernet classifier LFB where ARP protocol messages are 2083 categorized. The frame type hence expected is the ARP protocol 2084 message type. The other singleton input is for IPv4 packets that 2085 usually come from Ethernet encapsulator LFB and are unable to find L2 2086 information to finish encapsulation process in that LFB. The 2087 associated metadata include a next hop IPv4 address, which is the 2088 encapsulator LFB can not find its binding Ethernet MAC address, the 2089 logical port ID, and the VLAN ID (Editorial note: need more 2090 discussions on what metadata these inputs should expect.) 2092 There are two components defined in the ARP LFB. One is the ARP 2093 table. Note that ARP table in this LFB is defined as an alias 2094 component of ARP table in Ethernet encapsulator LFB. This means 2095 management of the ARP table will be shared by both of the LFBs. The 2096 ARP LFB will manage the table and refresh the table entries based on 2097 the ARP protocol messages received. The protocol messages provide 2098 bindings of IPv4 addresses with destination MAC addresses. The ARP 2099 table fields include destination IP address, logical port ID, source 2100 MAC address, and destination MAC address (Editorial note: need more 2101 discussions on what fields needed). 2103 Another component defined is the local IPv4 address table for all 2104 ports of the FE. An FE port here is indexed by a logical port ID. 2105 Note that every physical port may be capable of multiple logical 2106 ports with multiple IP or MAC addresses. The port IPv4 address table 2107 provides binding of a logical port to an IP address and a MAC address 2108 (Editorial note: is it possible one logical port binds multiple IP 2109 addresses?). The table will be used by the ARP LFB to check locality 2110 of arrived ARP protocol messages. Usually the table will be 2111 configured by CE via ForCES protocol.(Editorial note: need more 2112 discussions on what fields the port IP address table needs and how 2113 the logical port ID and MAC address take effect in the process). 2115 Two singleton outputs are defined for the ARP LFB. One is for ARP 2116 protocol message output. All ARP request and response packets are 2117 sent out from here to downstream LFB, which usually is Ethernet 2118 encapsulation LFB. 2120 Another output is for sending all packets that are input to this LFB 2121 because they can not find L2 encapsulation information when doing 2122 encapsulation in an Ethernet encapsulation LFB. They are just sent 2123 back to the LFB for encapsulation again with the expected refreshed 2124 ARP table contents. (Editorial note: need more discussions on how 2125 the mechanism should be defined for those packets unable to do 2126 encapsulation in encapsulation LFB. An alternative schema is to let 2127 the ARP LFB to do encapsulation rather than send them back to 2128 encapsulation LFB, then output the packets directly to an LFB after 2129 the encapsulation LFB). 2131 5.4.2. ND 2133 (TBD) 2135 5.5. Redirect LFBs 2137 Redirect LFBs abstract data packets transportation process between CE 2138 and FE. Some packets output from some LFBs may have to be delivered 2139 to CE for further processing, and some packets generated by CE may 2140 have to be delivered to FE and further to some specific LFBs for data 2141 path processing. According to RFC 5810 [RFC5810], data packets and 2142 their associated metadata are encapsulated in ForCES redirect message 2143 for transportation between CE and FE. We define two LFBs to abstract 2144 the process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an 2145 LFB topology of an FE, only one RedirectIn LFB instance and one 2146 RedirectOut LFB instance exist. 2148 5.5.1. RedirectIn 2150 A RedirectIn LFB abstracts the process for CE to inject data packets 2151 into FE LFB topology so as to input data packets into FE data paths. 2152 From LFB topology point of view, the RedirectIn LFB acts as a source 2153 point for data packets coming from CE, therefore the RedirectIn LFB 2154 is defined with only one output, while without any input. 2156 Output of the RedirectIn LFB is defined as a group output. Packets 2157 produced by the output will have arbitrary frame types decided by CE 2158 which generates the packets. Possible frames may include IPv4, IPv6, 2159 or ARP protocol packets. CE may associate some metadata to indicate 2160 the frame types. CE may also associate other metadata to data 2161 packets to indicate various information on the packets. Among them, 2162 there MUST exist a 'RedirectIndex' metadata, which is an integer 2163 acting as an index. When CE transmits the metadata and a binging 2164 packet to a RedirectIn LFB, the LFB will read the metadata and output 2165 the packet to one of its group output port instance, whose port index 2166 is just as indicated by the metadata. Detailed XML definition of the 2167 metadata is in the XML for base type library as in Section 4.4. 2169 All metadata from CE other than the 'RedirectIndex' metadata will 2170 output from the RedirectIn LFB along with their binding packets. 2171 Note that, a packet without a 'RedirectIndex' metadata associated 2172 will be dropped by the LFB. 2174 There is no component defined for current version of RedirectIn LFB. 2175 Detailed XML definitions of the LFB can be found in Section 6. 2177 5.5.2. RedirectOut 2179 A RedirectOut LFB abstracts the process for LFBs in FE to deliver 2180 data packets to CE. From LFB topology point of view, the RedirectOut 2181 LFB acts as a sink point for data packets going to CE, therefore the 2182 RedirectOut LFB is defined with only one input, while without any 2183 output. 2185 Input of the RedirectOut LFB is defined as a singleton input, but it 2186 is capable of receiving packets from multiple LFBs by multiplexing 2187 the singleton input. Packets expected by the input will have 2188 arbitrary frame types. All metadata associated with the input 2189 packets will be delivered to CE via a ForCES protocol redirect 2190 message [RFC5810]. The input will expect all types of metadata. 2192 There is no component defined for current version of RedirectOut LFB. 2193 Detailed XML definitions of the LFB can be found in Section 6. 2195 5.6. General Purpose LFBs 2197 5.6.1. BasicMetadataDispatch 2199 A basic medatata dispatch LFB is defined to abstract a process in 2200 which a packet is dispatched to some path based on its associated 2201 metadata value. 2203 The LFB is with a singleton input. Packets of arbitrary frame types 2204 can input into the LFB. Whereas, every input packet is required to 2205 be associated with a metadata that will be used by the LFB to do 2206 dispatch. If a packet is not associated with such metadata, the 2207 packet will be dropped inside the LFB. 2209 A group of output is defined to output packets according to a 2210 MetaDispatchTable as defined a component in the LFB. The table 2211 contains the fields of a metadata ID, a metadata value, and an output 2212 port index. A packet, if it is associated with a metadata with the 2213 metadata ID, will be output to the group port instance with the index 2214 corresponding to the metadata value in the table. The metadata value 2215 ussed by the table is required with an interger data type. This 2216 means this LFB currently only allow a metadata with an interger value 2217 to be used for dispatch. 2219 Moreover, the LFB is defined with only one metadata adopted for 2220 dispatch, i.e., the metadata ID in the dispatch table is always the 2221 same for all table rows. 2223 A more complex metadata dispatch LFB may be defined in future version 2224 of the library. In that LFB, multiple tuples of metadata may be 2225 adopted to dispatch packets. 2227 5.6.2. GenericScheduler 2229 There exist various kinds of scheduling strategies with various 2230 implementations. As a base LFB library, this document only defines a 2231 preliminary generic scheduler LFB for abstracting a simple scheduling 2232 process. The generic scheduler LFB is the one. Users may use this 2233 LFB as a basic scheduler LFB to further construct more complex 2234 scheduler LFBs by means of inheritance as described in RFC 5812 2235 [RFC5812]. 2237 The LFB describes scheduling process in the following model: 2239 o It is with a group input and expects packets with arbitrary frame 2240 types to arrive for scheduling. The group input is capable of 2241 multiple input port instances. Each port instance may be 2242 connected to different upstream LFB output. No metadata is 2243 expected for each input packet. 2245 o Multiple queues reside at the input side, with every input port 2246 instance connected to one queue. 2248 o Every queue is marked with a queue ID, and the queue ID is exactly 2249 the same as the index of corresponding input port instance. 2251 o Scheduling disciplines are applied to all queues and also all 2252 packets in the queues. 2254 o Scheduled packets are output from a singleton output port of the 2255 LFB. 2257 Two LFB components are defined to further describe above model. A 2258 scheduling discipline component is defined for CE to specify a 2259 scheduling discipline to the LFB. Currently defined scheduling 2260 disciplines only include FIFO and round robin(RR). For FIFO, we 2261 limit above model that when a FIFO discipline is applied, it is 2262 require that there is only one input port instance for the group 2263 input. If user accidentally defines multiple input port instances 2264 for FIFO scheduling, only packets in the input port with lowest port 2265 index will be scheduled to output port, and all packets in other 2266 input port instances will just ignored. 2268 We specify that if the generic scheduler LFB is defined only one 2269 input port instance, the default scheduling discipline is FIFO. If 2270 the LFB is defined with more than one input port instances, the 2271 default scheduling discipline is round robin (RR). 2273 A current queue depth component is defined to allow CE to query every 2274 queue status of the scheduler. Using the queue ID as the index, CE 2275 can query every queue for its used length in unit of packets or 2276 bytes. 2278 Several capabilities are defined for the LFB. A queue number limit 2279 is defined which limits the scheduler maximum supported queue number, 2280 which is also the maximum number of input port instances. Capability 2281 of disciplines supported provides scheduling discipline types 2282 supported by the FE to CE. Queue length limit provides the 2283 capability of storage ability for every queue. 2285 More complex scheduler LFB may be defined with more complex 2286 scheduling discipline by succeeding this LFB. For instance, a 2287 priority scheduler LFB may be defined only by inheriting this LFB and 2288 define a component to indicate priorities for all input queues. 2290 See Section 6 for detailed XML definition for this LFB. 2292 6. XML for LFB Library 2294 2297 2298 2299 2300 EtherPHYCop 2301 The LFB describes an Ethernet port abstracted at 2302 physical layer.It limits its physical media to copper. 2303 Multiple virtual PHYs isn't supported in this LFB version. 2304 2305 1.0 2306 2307 2308 EtherPHYIn 2309 The Input Port of the EtherPHYLFB. It 2310 expects any kind of Ethernet frame. 2311 2312 2313 EthernetAll 2314 2315 2316 2317 2318 2319 2320 EtherPHYOut 2321 The Output Port of the EtherPHYLFB. It can 2322 produce any kind of Ethernet frame and along with 2323 the frame passes the ID of the Physical Port as 2324 metadata to be used by the next LFBs. 2325 2326 2327 EthernetII 2328 2329 2330 PHYPortID 2331 2332 2333 2334 2335 2336 2337 PHYPortID 2338 The ID of the physical port that this LFB 2339 handles. 2340 uint32 2341 2342 2343 AdminLinkSpeed 2344 The link speed that the admin has requested. 2345 2346 LANSpeedType 2347 0x00000005 2348 2349 2350 OperLinkSpeed 2351 The actual operational link speed. 2352 LANSpeedType 2353 2354 2355 AdminDuplexMode 2356 The duplex mode that the admin has requested. 2357 2358 DuplexType 2359 0x00000001 2360 2361 2362 OperDuplexMode 2363 The actual duplex mode. 2364 DuplexType 2365 2366 2367 AdminStatus 2368 Status of the port 2369 PortStatusValues 2370 2 2371 2372 2373 CarrierStatus 2374 The status of the Carrier. Whether the port 2375 is linked with an operational connector. 2376 boolean 2377 0 2378 2379 2380 PHYPortStats 2381 Statistics of the Physical Port. 2382 PHYPortStatsType 2383 2384 2385 2386 2387 SupportedLinkSpeed 2388 Supported Link Speeds 2389 2390 LANSpeedType 2391 2392 2393 2394 SupportedDuplexMode 2395 Supported Duplex Modes 2396 2397 DuplexType 2398 2399 2400 2401 2402 2403 PHYPortStatusChanged 2404 When the status of the Physical port is 2405 changed,the LFB sends the new status. 2406 2407 AdminStatus 2408 2409 2410 2411 2412 AdminStatus 2413 2414 2415 2416 2417 LinkSpeedChanged 2418 When the operational speed of the link 2419 is changed, the LFB sends the new operational link 2420 speed. 2421 2422 OperLinkSpeed 2423 2424 2425 2426 2427 OperLinkSpeed 2428 2429 2430 2431 2432 2433 2434 EtherMACIn 2435 a LFB abstracts an Ethernet port at MAC data link 2436 layer. Multiple virtual MACs isn't supported in this LFB 2437 version. 2438 1.0 2439 2440 2441 EtherMACIn 2442 The Input Port of the EtherMACIn. It 2443 expects any kind of Ethernet frame. 2444 2445 2446 EthernetAll 2447 2448 2449 PHYPortID 2450 2451 2452 2453 2454 2455 2456 NormalPathOut 2457 The Normal Output Port of the EtherMACIn. 2458 It can produce any kind of Ethernet frame and along 2459 with the frame passes the ID of the Physical Port as 2460 metadata to be used by the next LFBs. 2461 2462 2463 EthernetAll 2464 2465 2466 PHYPortID 2467 2468 2469 2470 2471 L2BridgingPathOut 2472 The Bridging Output Port of the EtherMACIn. 2473 It can produce any kind of Ethernet frame and along 2474 with the frame passes the ID of the Physical Port as 2475 metadata to be used by the next LFBs. 2476 2477 2478 EthernetAll 2479 2480 2481 PHYPortID 2482 2484 2485 2486 2487 2488 2489 OperStatus 2490 Operational Status of the LFB. 2491 PortStatusValues 2492 2493 2494 LocalMACAddresses 2495 Local Mac Addresses 2496 2497 IEEEMAC 2498 2499 2500 2501 L2BridgingPathEnable 2502 Is the LFB doing L2 Bridging? 2503 boolean 2504 false 2505 2506 2507 PromiscuousMode 2508 Is the LFB in Promiscuous Mode? 2509 boolean 2510 false 2511 2512 2513 TxFlowControl 2514 Transmit Flow control 2515 boolean 2516 false 2517 2518 2519 RxFlowControl 2520 Receive Flow control 2521 boolean 2522 false 2523 2524 2525 MTU 2526 Maximum Transmission Unit 2527 uint32 2528 2529 2530 MACStats 2531 MAC statistics 2532 MACStatsType 2533 2534 2535 2536 2537 EtherClassifier 2538 LFB that decapsulates Ethernet II packets and 2539 classifies them. 2540 1.0 2541 2542 2543 EtherPktsIn 2544 Input port for data packet. 2545 2546 2547 Arbitrary 2548 2549 2550 2551 2552 2553 2554 ClassifyOut 2555 Classify Out 2556 2557 2558 Arbitrary 2559 2560 2561 2562 2563 2564 2565 EtherDispatchTable 2566 Ether classify dispatch table 2567 2568 EtherDispatchTableType 2569 2570 2571 2572 VlanInputTable 2573 Vlan input table 2574 2575 VlanInputTableType 2576 2577 2578 2579 EtherClassifyStats 2580 Ether Classify statistic table 2581 2582 EtherClassifyStatsType 2583 2584 2585 2586 2587 2588 MaxOutPutPorts 2589 Maximum number of ports in the output 2590 group. 2591 uint32 2592 2593 2594 2595 2596 EtherEncapsulator 2597 A LFB that performs packets ethernet L2 2598 encapsulation. 2599 1.0 2600 2601 2602 EncapIn 2603 A Single Packet Input 2604 2605 2606 IPv4 2607 IPv6 2608 2609 2610 2611 NexthopIPv4Addr 2612 NexthopIPv6Addr 2613 2614 OutputLogicalPortID 2615 2616 VlanPriority 2617 2618 2619 2620 2621 2622 2623 SuccessOut 2624 Output port for Packets which have found 2625 Ethernet L2 information and have been successfully 2626 encapsulated to an Ethernet packet. 2627 2628 2629 IPv4 2630 IPv6 2631 2632 2633 OutputLogicalPortID 2634 2635 2636 2637 2638 PakcetNoARPOut 2639 Output port for packets can't find the 2640 associated L2 information in the ARP table. 2641 2642 2643 IPv4 2644 2645 2646 OutputLogicalPortID 2647 NexthopIPAddr 2648 VlanPriority 2649 2650 2651 2652 2653 PakcetNoNbrOut 2654 Output port for packets can't find the 2655 associated L2 information in the Nbr table. 2656 2657 2658 IPv6 2659 2660 2661 OutputLogicalPortID 2662 NexthopIPAddr 2663 VlanPriority 2664 2665 2666 2667 2668 ExceptionOut 2669 All packets that fail with the other 2670 operations in this LFB are output via this port. 2671 2672 2673 2674 IPv4 2675 IPv6 2677 2678 2679 ExceptionID 2680 OutputLogicalPortID 2681 NexthopIPAddr 2682 VlanPriority 2683 2684 2685 2686 2687 2688 2689 ArpTable 2690 ARP table. 2691 2692 ArpTableType 2693 2694 2695 2696 NbrTable 2697 Nbr table. 2698 2699 NbrTableType 2700 2701 2702 2703 VLANOutputTable 2704 VLAN output table. 2705 2706 VLANOutputTableType 2707 2708 2709 2710 2711 2712 EtherMACOut 2713 EtherMACOut LFB abstracts an Ethernet port at MAC 2714 data link layer. It specifically describes Ethernet packet 2715 output process. Ethernet output functions are closely related 2716 to Ethernet input functions, therefore many components 2717 defined in this LFB are actually alias of EtherMACIn LFB. 2718 2719 1.0 2720 2721 2722 EtherPacketsIn 2723 The Input Port of the EtherMACIn. It expects 2724 any kind of Ethernet frame. 2725 2726 2727 EthernetAll 2728 2729 2730 PHYPortID 2731 2732 2733 2734 2735 2736 2737 EtherMACOut 2738 The Normal Output Port of the EtherMACOut. It 2739 can produce any kind of Ethernet frame and along with 2740 the frame passes the ID of the Physical Port as 2741 metadata to be used by the next LFBs. 2742 2743 2744 EthernetAll 2745 2746 2747 PHYPortID 2748 2749 2750 2751 2752 2753 2754 OperStatus 2755 Operational Status of the LFB. 2756 PortStatusValues 2757 2758 2759 TxFlowControl 2760 Transmit Flow control 2761 boolean 2762 false 2763 2764 2765 RxFlowControl 2766 Receive Flow control 2767 boolean 2768 false 2769 2770 2771 MACStats 2772 MAC statistics 2773 MACStatsType 2774 2775 2776 2777 2778 IPv4Validator 2779 a LFB that performs IPv4 packets validation 2780 according to RFC1812 and RFC2644. 2781 1.0 2782 2783 2784 ValidatePktsIn 2785 Input port for data packet. 2786 2787 2788 Arbitrary 2789 2790 2791 2792 2793 2794 2795 IPv4UnicastOut 2796 Output for IPv4 unicast packet. 2797 2798 2799 IPv4Unicast 2800 2801 2802 2803 2804 IPv4MulticastOut 2805 Output for IPv4 multicast packet. 2806 2807 2808 IPv4Multicast 2809 2810 2811 2812 2813 ExceptionOut 2814 Output for exception packet. 2815 2816 2817 IPv4 2818 2819 2820 ExceptionID 2822 2823 2824 2825 2826 FailOutput 2827 Output for failed validation packet. 2828 2829 2830 2831 IPv4 2832 2833 2834 ValidateErrorID 2835 2836 2837 2838 2839 2840 2841 IPv4ValidatorStats 2842 Ether classify dispatch table 2843 IPv4ValidatorStatisticsType 2844 2845 2846 2847 2848 IPv6Validator 2849 A LFB that performs IPv6 packets validation 2850 according to RFC2460 and RFC4291. 2851 1.0 2852 2853 2854 ValidatePktsIn 2855 Input port for data packet. 2856 2857 2858 Arbitrary 2859 2860 2861 2862 2863 2864 2865 IPv6UnicastOut 2866 Output for IPv6 unicast packet. 2867 2868 2869 IPv6Unicast 2871 2872 2873 2874 2875 IPv6MulticastOut 2876 Output for IPv6 multicast packet. 2877 2878 2879 IPv6Multicast 2880 2881 2882 2883 2884 ExceptionOut 2885 Output for exception packet. 2886 2887 2888 IPv6 2889 2890 2891 ExceptionID 2892 2893 2894 2895 2896 FailOutput 2897 Output for failed validation packet. 2898 2899 2900 2901 IPv6 2902 2903 2904 ValidateErrorID 2905 2906 2907 2908 2909 2910 2911 IPv6ValidatorStats 2912 Ether classify dispatch table 2913 IPv6ValidatorStatisticsType 2914 2915 2916 2917 2918 IPv4UcastLPM 2919 a LFB that performs IPv4 Longest Prefix Match 2920 Lookup. 2921 1.0 2922 2923 2924 PktIn 2925 A Single Packet Input 2926 2927 2928 IPv4Unicast 2929 2930 2931 DstIPv4Address 2932 2933 2934 2935 2936 2937 2938 NormalOut 2939 This output port is connected with 2940 IPv4NextHopApplicator LFB 2941 2942 2943 IPv4Unicast 2944 2945 2946 HopSelector 2947 2948 2949 2950 2951 ECMPOut 2952 This output port is connected with ECMP LFB, 2953 if there is ECMP LFB in the FE. 2954 2955 2956 IPv4Unicast 2957 2958 2959 HopSelector 2960 2961 2962 2963 2964 ExceptionOut 2965 The output for the packet if an exception 2966 occurs 2967 2968 2969 IPv4Unicast 2970 2971 2972 ExceptionID 2973 2974 2975 2976 2977 2978 2979 IPv4PrefixTable 2980 The IPv4 Prefix Table. 2981 2982 IPv4PrefixTableType 2983 2984 2985 2986 IPv4UcastLPMStats 2987 Statistics for IPv4 Unicast Longest Prefix 2988 Match 2989 IPv4UcastLPMStatsType 2990 2991 2992 2993 2994 IPv6UcastLPM 2995 A LFB that performs IPv6 Longest Prefix Match 2996 Lookup. 2997 1.0 2998 2999 3000 PktIn 3001 A Single Packet Input 3002 3003 3004 IPv6Unicast 3005 3006 3007 DstIPv6Address 3008 3009 3010 3011 3012 3013 3014 NormalOut 3015 This output port is connected with 3016 IPv6NextHopApplicator LFB 3017 3018 3019 IPv6Unicast 3020 3021 3022 HopSelector 3023 3024 3025 3026 3027 ECMPOut 3028 This output port is connected with ECMP LFB, 3029 if there is ECMP LFB in the FE. 3030 3031 3032 IPv6Unicast 3033 3034 3035 HopSelector 3036 3037 3038 3039 3040 ExceptionOut 3041 The output for the packet if an exception 3042 occurs 3043 3044 3045 IPv6Unicast 3046 3047 3048 ExceptionID 3049 3050 3051 3052 3053 3054 3055 IPv6PrefixTable 3056 The IPv6 Prefix Table. 3057 3058 IPv6PrefixTableType 3059 3060 3061 3062 IPv6UcastLPMStats 3063 Statistics for IPv6 Unicast Longest Prefix 3064 Match 3065 IPv6UcastLPMStatsType 3066 3067 3068 3069 3070 IPv4NextHopApplicator 3071 A LFB for applicating next hop action to IPv4 3072 packets,the actions include:TTL operation,checksum 3073 recalculation. The input packets with the metadata 3074 "HopSelector"(the nexthop ID), get the nexthop 3075 information through looking up nexthop table. 3076 1.0 3077 3078 3079 PktIn 3080 A Single Packet Input 3081 3082 3083 IPv4Unicast 3084 3085 3086 HopSelector 3087 3088 3089 3090 3091 3092 3093 SuccessOut 3094 The output for the packet if it is valid to be 3095 forwarded 3096 3097 3098 IPv4Unicast 3099 3100 3101 OutputLogicalPortID 3102 NextHopIPv4Addr 3103 3104 3105 3106 3107 ExceptionOut 3108 The output for the packet if an exception 3109 occurs 3110 3111 3112 IPv4Unicast 3113 3114 3115 ExceptionID 3116 3117 3118 3119 3120 3121 3122 IPv4NextHopTable 3123 The Next Hop Table. 3124 3125 IPv4NextHopTableType 3126 3127 3128 3129 3130 3131 MaxOutPutPorts 3132 Maximum number of ports in the output group. 3133 3134 uint32 3135 3136 3137 3138 3139 IPv6NextHopApplicator 3140 A LFB definition for applicating next hop action to 3141 IPv6 packets,the actions include:TTL operation,checksum 3142 recalculation. The input packets with the metadata 3143 "HopSelector"(the nexthop ID), get the nexthop information 3144 through looking up nexthop table. 3145 1.0 3146 3147 3148 PktIn 3149 A Single Packet Input 3150 3151 3152 IPv6Unicast 3153 3154 3155 HopSelector 3156 3157 3158 3160 3161 3162 3163 SuccessOut 3164 The output for the packet if it is valid to 3165 be forwarded 3166 3167 3168 IPv6Unicast 3169 3170 3171 OutputLogicalPortID 3172 NextHopIPv6Addr 3173 3174 3175 3176 3177 ExceptionOut 3178 The output for the packet if an exception 3179 occurs 3180 3181 3182 IPv6Unicast 3183 3184 3185 ExceptionID 3186 3187 3188 3189 3190 3191 3192 IPv6NextHopTable 3193 The Next Hop Table. 3194 3195 IPv6NextHopTableType 3196 3197 3198 3199 3200 3201 MaxOutPutPorts 3202 Maximum number of ports in the output group. 3203 3204 uint32 3205 3206 3207 3208 3209 ARP 3210 ARP 3211 1.0 3212 3213 3214 ArpPktsIn 3215 The input port for ARP packets. 3216 3217 3218 ARP 3219 3220 3221 PHYPortID 3222 LogicalPortID 3223 SrcMAC 3224 DstMAC 3225 3226 3227 3228 3229 AddrResDataPktIn 3230 The input port for the packet which need 3231 address resolution.. 3232 3233 3234 IPv4 3235 3236 3237 NexthopIPv4Addr 3238 OutputLogicalPortID 3239 3240 VlanID 3241 3242 VlanPriority 3243 3244 3245 3246 3247 3248 3249 ArpOut 3250 The output port for Arp packets. 3251 3252 3253 EthernetII 3254 3255 3256 OutputLogicalPortID 3257 3258 3259 3260 3261 AddrResDataPktOut 3262 The output port for the packet which has been 3263 encapsulated with the L2 head. 3264 3265 3266 EthernetII 3267 3268 3269 OutputLogicalPortID 3270 3271 3272 3273 3274 3275 3276 PortV4AddrInfoTable 3277 The IPv4 address for all local ports. 3278 3279 3280 Portv4AddrInfoTableType 3281 3282 3283 3284 3285 3286 ND 3287 TBD 3288 1.0 3289 3290 3291 RedirectIn 3292 The RedirectIn LFB abstracts the process for CE to 3293 inject data packets into FE LFB topology so as to input data 3294 packets into FE data paths. From LFB topology point of view, 3295 the RedirectIn LFB acts as a source point for data packets 3296 coming from CE, therefore the RedirectIn LFB is defined with 3297 only one output, while without any input. Output of the 3298 RedirectIn LFB is defined as a group output. Packets produced 3299 by the output will have arbitrary frame types decided by CE 3300 which generates the packets. Possible frames may include IPv4, 3301 IPv6, or ARP protocol packets. CE may associate some metadata 3302 to indicate the frame types. CE may also associate other 3303 metadata to data packets to indicate various information on 3304 the packets. Among them, there MUST exist a 'RedirectIndex' 3305 metadata, which is an integer acting as an index. When CE 3306 transmits the metadata and a binging packet to a RedirectIn 3307 LFB, the LFB will read the metadata and output the packet to 3308 one of its group output port instance, whose port index is 3309 just as indicated by the metadata.All metadata from CE other 3310 than the 'RedirectIndex' metadata will output from the 3311 RedirectIn LFB along with their binding packets. Note that, 3312 a packet without a 'RedirectIndex' metadata associated 3313 will be dropped by the LFB. 3314 1.0 3315 3316 3317 PacketOut 3318 This output group sends the redirected packet 3319 in the data path. 3320 3321 3322 Arbitrary 3323 3324 3325 3326 3327 3328 3329 MaxOutPutPorts 3330 Maximum number of ports in the output group 3331 3332 uint32 3333 3334 3335 3336 3337 RedirectOut 3338 A RedirectOut LFB abstracts the process for LFBs in 3339 FE to deliver data packets to CE. From LFB topology point of 3340 view, the RedirectOut LFB acts as a sink point for data 3341 packets going to CE, therefore the RedirectOut LFB is defined 3342 with only one input, while without any output.Input of the 3343 RedirectOut LFB is defined as a singleton input, but it is 3344 capable of receiving packets from multiple LFBs by 3345 multiplexing the singleton input. Packets expected by the 3346 input will have arbitrary frame types. All metadata 3347 associated with the input packets will be delivered to CE 3348 via the redirect message of ForCES protocol [RFC5810], 3349 therefore the input will expect all types of metadata. 3350 3351 1.0 3352 3353 3354 PacketIn 3355 This input group receives packets to send to 3356 the CE. 3357 3358 3359 Arbitrary 3360 3361 3362 3363 3364 3365 3366 BasicMetadataDispatch 3367 This LFB provides the function to dispatch input 3368 packets to a group output according to a metadata and a 3369 dispatch table. 3370 1.0 3371 3372 3373 PacketsIn 3374 Input port for data packet. 3375 3376 3377 Arbitrary 3378 3379 3380 Arbitrary 3381 3382 3383 3384 3385 3386 3387 PacketsOut 3388 Data packet output 3389 3390 3391 Arbitrary 3392 3393 3394 3395 3396 3397 3398 MetadataDispatchTable 3399 metadata dispatch table. 3400 MetadataDispatchTableType 3401 3402 3403 3404 3405 MaxOutPutPorts 3406 Maxium number of ports in the output group. 3407 3408 uint32 3409 3410 3411 3412 3413 GenericScheduler 3414 Generic Scheduler LFB. 3415 1.0 3416 3417 3418 PacketsIn 3419 Input port for data packet. 3420 3421 3422 Arbitrary 3423 3424 3425 3426 3427 3428 3429 PacketsOut 3430 Data packet output 3431 3432 3433 Arbitrary 3434 3435 3436 3437 3438 3439 3440 QueueCount 3441 the number of queues to be scheduled. 3442 3443 uint32 3444 3445 3446 SchedulingDiscipline 3447 the Scheduler discipline. 3448 SchdDisciplineType 3449 3450 3451 CurrentQueueDepth 3452 Current Depth of all queues 3453 3454 QueueDepth 3455 3456 3457 3458 3459 3460 QueueLenLimit 3461 Maximum length of each queue,the unit is 3462 byte. 3463 uint32 3464 3465 3466 QueueScheduledLimit 3467 Max number of queues that can be scheduled by 3468 this scheduluer. 3469 uint32 3470 3471 3472 DisciplinesSupported 3473 the scheduling disciplines supported. 3474 3475 3476 SchdDisciplineType 3477 3478 3479 3480 3481 3482 3484 7. Use Library for Typical Router Functions 3486 This section demonstrates examples on how the LFB classes defined by 3487 the Base LFB library in Section 6 are applied to achieve typical 3488 router functions. 3490 As mentioned in the overview section, typical router functions can be 3491 categorized in short into the following functions: 3493 o IP forwarding 3495 o address resolution 3497 o ICMP 3499 o network management 3501 o running routing protocol 3503 To achieve the functions, processing paths organized by the LFB 3504 classes with their interconnections should be established in FE. In 3505 general, CE controls and manages the processing paths by use of the 3506 ForCES protocol. 3508 Note that LFB class use cases shown in this section are only as 3509 examples to demonstrate how typical router functions can be 3510 implemented with the defined base LFB library. Users and 3511 implementers should not be limited by the examples. 3513 7.1. IP Forwarding 3515 Figure 1 shows the typical LFB processing path for the IPv4 unicast 3516 forwarding case with Ethernet media interfaces. 3518 +-----+ +------+ 3519 | | | | 3520 | |<---------------|Ether |<----------------------------+ 3521 | | |MACOut| | 3522 | | | | | 3523 |Ether| +------+ | 3524 |MAC | | 3525 |Cop | +---+ | 3526 |#1 | +-----+ | |----->IPv6 Packets | 3527 | | | | | | +----+ | 3528 | | |Ether| | | | | | 3529 | |->|MACIn|-->| |IPv4| | | 3530 +-----+ | | | |-+->| | +---+ | 3531 +-----+ +--+ | | |unicast +-----+ | | | 3532 Ether | | |------->| | | | | 3533 . Classifier| | |packet |IPv4 | | | | 3534 . | | | |Ucast|->| |--+ | 3535 . | | | |LPM | | | | | 3536 +---+ | +----+ +-----+ | | | | 3537 +-----+ | | | IPv4 +---+ | | 3538 | | | | | Validator IPv4 | | 3539 +-----+ |Ether| | |-+ NextHop | | 3540 | |->|MACIn|-->| |IPv4 Applicator| | 3541 | | | | | |----->IPv6 Packets | | 3542 |Ether| +-----+ +---+ +----+ | | 3543 |MAC | Ether | | | | 3544 |Cop | Classifier | | +-------+ | | 3545 |#n | | | | | | | 3546 | | +------+ | |<--| Ether |<-+ | 3547 | | | |<------| | | Encap | | 3548 | |<---------------|Ether | ...| | +-------+ | 3549 | | |MACOut| +---| | | 3550 | | | | | +----+ | 3551 +-----+ +------+ | BasicMetadataDispatch | 3552 +-------------------------+ 3554 Figure 1 IPv4 Forwarding case 3556 Figure 2 shows the typical LFB processing path for the IPv6 unicast 3557 forwarding case with media ports not considered. 3559 Figure 2. (TBD) 3561 7.2. Address Resolution 3563 TBD 3565 7.3. ICMP 3567 TBD 3569 7.4. Running Routing Protocol 3571 TBD 3573 7.5. Network Management 3575 TBD 3577 8. Contributors 3579 The authors would like to thank Jamal Hadi Salim and Ligang Dong who 3580 made a major contribution to the development of this document. 3582 Jamal Hadi Salim 3583 Mojatatu Networks 3584 Ottawa, Ontario 3585 Canada 3586 Email: hadi@mojatatu.com 3588 Ligang Dong 3589 Zhejiang Gongshang University 3590 149 Jiaogong Road 3591 Hangzhou 310035 3592 P.R.China 3593 Phone: +86-571-28877751 3594 EMail: donglg@mail.zjgsu.edu.cn 3596 9. Acknowledgements 3598 This document is based on earlier documents from Joel Halpern, Ligang 3599 Dong, Fenggen Jia and Weiming Wang. 3601 10. IANA Considerations 3603 (TBD) 3605 11. Security Considerations 3607 These definitions if used by an FE to support ForCES create 3608 manipulable entities on the FE. Manipulation of such objects can 3609 produce almost unlimited effects on the FE. FEs should ensure that 3610 only properly authenticated ForCES protocol participants are 3611 performing such manipulations. Thus the security issues with this 3612 protocol are defined in the ForCES protocol [RFC5810]. 3614 12. References 3616 12.1. Normative References 3618 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 3619 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 3620 Control Element Separation (ForCES) Protocol 3621 Specification", RFC 5810, March 2010. 3623 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 3624 Element Separation (ForCES) Forwarding Element Model", 3625 RFC 5812, March 2010. 3627 12.2. Informative References 3629 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 3630 RFC 1812, June 1995. 3632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3633 Requirement Levels", BCP 14, RFC 2119, March 1997. 3635 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3636 June 1999. 3638 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3639 Text on Security Considerations", BCP 72, RFC 3552, 3640 July 2003. 3642 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3643 of IP Control and Forwarding", RFC 3654, November 2003. 3645 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3646 "Forwarding and Control Element Separation (ForCES) 3647 Framework", RFC 3746, April 2004. 3649 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3650 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3651 May 2008. 3653 Authors' Addresses 3655 Weiming Wang 3656 Zhejiang Gongshang University 3657 18, Xuezheng Str., Xiasha University Town 3658 Hangzhou, 310018 3659 P.R.China 3661 Phone: +86-571-28877721 3662 Email: wmwang@zjgsu.edu.cn 3664 Evangelos Haleplidis 3665 University of Patras 3666 Patras, 3667 Greece 3669 Email: ehalep@ece.upatras.gr 3671 Kentaro Ogawa 3672 NTT Corporation 3673 Tokyo, 3674 Japan 3676 Email: ogawa.kentaro@lab.ntt.co.jp 3678 Fenggen Jia 3679 National Digital Switching Center(NDSC) 3680 Jianxue Road 3681 Zhengzhou, 452000 3682 P.R.China 3684 Phone: +86-571-28877751 3685 Email: jfg@mail.ndsc.com.cn,fgjia@mail.zjgsu.edu.cn 3687 Halpern Joel 3688 Ericsson 3689 P.O. Box 6049 3690 Leesburg, 20178 3691 VA 3693 Phone: +1 703 371 3043 3694 Email: joel.halpern@ericsson.com