idnits 2.17.1
draft-ietf-forces-lfb-lib-07.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 12, 2012) is 4486 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'N' is mentioned on line 510, but not defined
== Unused Reference: 'RFC1812' is defined on line 4387, but no explicit
reference was found in the text
== Unused Reference: 'RFC2629' is defined on line 4396, but no explicit
reference was found in the text
== Unused Reference: 'RFC3552' is defined on line 4399, but no explicit
reference was found in the text
== Unused Reference: 'RFC3654' is defined on line 4403, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 2460
(Obsoleted by RFC 8200)
-- 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: 0 errors (**), 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: July 15, 2012 University of Patras
6 K. Ogawa
7 NTT Corporation
8 C. Li
9 Hangzhou H3C Tech. Co., Ltd.
10 J. Halpern
11 Ericsson
12 January 12, 2012
14 ForCES Logical Function Block (LFB) Library
15 draft-ietf-forces-lfb-lib-07
17 Abstract
19 This document defines basic classes of Logical Function Blocks (LFBs)
20 used in the Forwarding and Control Element Separation (ForCES). The
21 basic LFB classes are defined according to ForCES FE model and ForCES
22 protocol specifications, and are scoped to meet requirements of
23 typical router functions and considered as the basic LFB library for
24 ForCES. The library includes the descriptions of the LFBs and the
25 XML definitions.
27 Status of this Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at http://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on July 15, 2012.
44 Copyright Notice
46 Copyright (c) 2012 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
64 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
65 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . 8
66 3.2. Overview of LFB Classes in the Library . . . . . . . . . 10
67 3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . 10
68 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 10
69 3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12
70 3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13
71 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 15
72 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 15
73 4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 15
74 4.1.2. Compound struct . . . . . . . . . . . . . . . . . . . 16
75 4.1.3. Compound array . . . . . . . . . . . . . . . . . . . 16
76 4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 17
77 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 17
78 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 18
79 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 40
80 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 40
81 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 41
82 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 43
83 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 44
84 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 47
85 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 49
86 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 50
87 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 50
88 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 52
89 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 53
90 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 54
91 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 56
92 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 58
93 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 60
94 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 62
95 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 62
96 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 63
97 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 64
98 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 64
99 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 65
100 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 68
101 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 90
102 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 90
103 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 91
104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 94
105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95
106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
107 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 96
108 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 98
109 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 98
110 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 99
111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 101
112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 102
113 12.1. Normative References . . . . . . . . . . . . . . . . . . 102
114 12.2. Informative References . . . . . . . . . . . . . . . . . 102
115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103
117 1. Terminology and Conventions
119 1.1. Requirements Language
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
123 document are to be interpreted as described in [RFC2119].
125 2. Definitions
127 This document follows the terminology defined by the ForCES protocol
128 in [RFC5810] and by the ForCES FE model in [RFC5812]. The
129 definitions below are repeated for clarity.
131 Control Element (CE) - A logical entity that implements the ForCES
132 protocol and uses it to instruct one or more FEs on how to process
133 packets. CEs handle functionality such as the execution of
134 control and signaling protocols.
136 Forwarding Element (FE) - A logical entity that implements the
137 ForCES protocol. FEs use the underlying hardware to provide per-
138 packet processing and handling as directed/controlled by one or
139 more CEs via the ForCES protocol.
141 ForCES Network Element (NE) - An entity composed of one or more
142 CEs and one or more FEs. To entities outside an NE, the NE
143 represents a single point of management. Similarly, an NE usually
144 hides its internal organization from external entities.
146 LFB (Logical Function Block) - The basic building block that is
147 operated on by the ForCES protocol. The LFB is a well defined,
148 logically separable functional block that resides in an FE and is
149 controlled by the CE via ForCES protocol. The LFB may reside at
150 the FE's datapath and process packets or may be purely an FE
151 control or configuration entity that is operated on by the CE.
152 Note that the LFB is a functionally accurate abstraction of the
153 FE's processing capabilities, but not a hardware-accurate
154 representation of the FE implementation.
156 FE Model - The FE model is designed to model the logical
157 processing functions of an FE, which is defined by the ForCES FE
158 model document [RFC5812]. The FE model proposed in this document
159 includes three components; the LFB modeling of individual Logical
160 Functional Block (LFB model), the logical interconnection between
161 LFBs (LFB topology), and the FE-level attributes, including FE
162 capabilities. The FE model provides the basis to define the
163 information elements exchanged between the CE and the FE in the
164 ForCES protocol [RFC5810].
166 FE Topology - A representation of how the multiple FEs within a
167 single NE are interconnected. Sometimes this is called inter-FE
168 topology, to be distinguished from intra-FE topology (i.e., LFB
169 topology).
171 LFB Class and LFB Instance - LFBs are categorized by LFB Classes.
172 An LFB Instance represents an LFB Class (or Type) existence.
173 There may be multiple instances of the same LFB Class (or Type) in
174 an FE. An LFB Class is represented by an LFB Class ID, and an LFB
175 Instance is represented by an LFB Instance ID. As a result, an
176 LFB Class ID associated with an LFB Instance ID uniquely specifies
177 an LFB existence.
179 LFB Metadata - Metadata is used to communicate per-packet state
180 from one LFB to another, but is not sent across the network. The
181 FE model defines how such metadata is identified, produced and
182 consumed by the LFBs. It defines the functionality but not how
183 metadata is encoded within an implementation.
185 LFB Component - Operational parameters of the LFBs that must be
186 visible to the CEs are conceptualized in the FE model as the LFB
187 components. The LFB components include, for example, flags,
188 single parameter arguments, complex arguments, and tables that the
189 CE can read and/or write via the ForCES protocol (see below).
191 LFB Topology - Representation of how the LFB instances are
192 logically interconnected and placed along the datapath within one
193 FE. Sometimes it is also called intra-FE topology, to be
194 distinguished from inter-FE topology.
196 Data Path - A conceptual path taken by packets within the
197 forwarding plane inside an FE. Note that more than one data path
198 can exist within an FE.
200 ForCES Protocol - While there may be multiple protocols used
201 within the overall ForCES architecture, the term "ForCES protocol"
202 and "protocol" refer to the Fp reference points in the ForCES
203 Framework in [RFC3746]. This protocol does not apply to CE-to-CE
204 communication, FE-to-FE communication, or to communication between
205 FE and CE managers. Basically, the ForCES protocol works in a
206 master-slave mode in which FEs are slaves and CEs are masters.
207 This document defines the specifications for this ForCES protocol.
209 LFB Port - A port refers to an LFB input port or output port. See
210 Section 3.2 of [RFC5812] for more detailed definitions.
212 Physical Port - A port refers to a physical media input port or
213 output port of an FE. A physical port is usually assigned with a
214 physical port ID, abbreviated with a PHYPortID. This document
215 mainly deals with physical ports with Ethernet media.
217 Logical Port - A conceptually virtual port at data link layer (L2)
218 or network layer (L3). A logical port is usually assigned with a
219 logical port ID, abbreviated with a LogicalPortID. The logical
220 ports can be further categorized with a L2 logical port or a L3
221 logical port. An L2 logical port can be assigned with a L2
222 logical port ID, abbreviated with a L2PortID. An L3 logical port
223 can be assigned with a L3 logical port ID, abbreviated with a
224 L3PortID. MAC layer VLAN ports belongs to L2 logical ports as
225 well as logical ports.
227 LFB Class Library - The LFB class library is a set of LFB classes
228 that has been identified as the most common functions found in
229 most FEs and hence should be defined first by the ForCES Working
230 Group. The LFB Class Library is defined by this document.
232 3. Introduction
234 [RFC5810] specifies Forwarding and Control Element Separation
235 (ForCES) framework. In the framework, Control Elements (CEs)
236 configure and manage one or more separate Forwarding Elements (FEs)
237 within a Network Element (NE) by use of a ForCES protocol. [RFC5810]
238 specifies the ForCES protocol. [RFC5812] specifies the Forwarding
239 Element (FE) model. In the model, resources in FEs are described by
240 classes of Logical Function Blocks (LFBs). The FE model defines the
241 structure and abstract semantics of LFBs, and provides XML schema for
242 the definitions of LFBs.
244 This document conforms to the specifications of the FE model
245 [RFC5812] and specifies detailed definitions of classes of LFBs,
246 including detailed XML definitions of LFBs. These LFBs form a base
247 LFB library for ForCES. LFBs in the base library are expected to be
248 combined to form an LFB topology for a typical router to implement IP
249 forwarding. It should be emphasized that an LFB is an abstraction of
250 functions rather than its implementation details. The purpose of the
251 LFB definitions is to represent functions so as to provide
252 interoperability between separate CEs and FEs.
254 More LFB classes with more functions may be developed in future time
255 and documented by IETF. Vendors may also develop proprietary LFB
256 classes as described in the FE model [RFC5812].
258 3.1. Scope of the Library
260 It is intended that the LFB classes described in this document are
261 designed to provide the functions of a typical router. [RFC5812]
262 specifies that a typical router is expected to provide functions to:
264 (1) Interface to packet networks and implement the functions
265 required by that network. These functions typically include:
267 * Encapsulating and decapsulating the IP datagrams with the
268 connected network framing (e.g., an Ethernet header and
269 checksum),
271 * Sending and receiving IP datagrams up to the maximum size
272 supported by that network, this size is the network's Maximum
273 Transmission Unit or MTU,
275 * Translating the IP destination address into an appropriate
276 network-level address for the connected network (e.g., an
277 Ethernet hardware address), if needed, and
279 * Responding to network flow control and error indications, if
280 any.
282 (2) Conform to specific Internet protocols including the Internet
283 Protocol (IPv4 and/or IPv6), Internet Control Message Protocol
284 (ICMP), and others as necessary.
286 (3) Receive and forward Internet datagrams. Important issues in
287 this process are buffer management, congestion control, and
288 fairness.
290 * Recognizes error conditions and generates ICMP error and
291 information messages as required.
293 * Drops datagrams whose time-to-live fields have reached zero.
295 * Fragments datagrams when necessary to fit into the MTU of the
296 next network.
298 (4) Choose a next-hop destination for each IP datagram, based on the
299 information in its routing database.
301 (5) Usually support an interior gateway protocol (IGP) to carry out
302 distributed routing and reachability algorithms with the other
303 routers in the same autonomous system. In addition, some
304 routers will need to support an exterior gateway protocol (EGP)
305 to exchange topological information with other autonomous
306 systems. For all routers, it is essential to provide ability to
307 manage static routing items.
309 (6) Provide network management and system support facilities,
310 including loading, debugging, status reporting, exception
311 reporting and control.
313 The classical IP router utilizing the ForCES framework constitutes a
314 CE running some controlling IGP and/or EGP function or static route
315 setup and FEs implementing using Logical Function Blocks (LFBs)
316 conforming to the FE model[RFC5812] specifications. The CE, in
317 conformance to the ForCES protocol[RFC5810] and the FE model
318 [RFC5812] specifications, instructs the LFBs on the FE how to treat
319 received/sent packets.
321 Packets in an IP router are received and transmitted on physical
322 media typically referred to as "ports". Different physical port
323 media will have different ways for encapsulating outgoing frames and
324 decapsulating incoming frames. The different physical media will
325 also have different attributes that influence its behavior and how
326 frames get encapsulated or decapsulated. This document will only
327 deal with Ethernet physical media. Other future documents may deal
328 with other types of media. This document will also interchangeably
329 refer to a port to be an abstraction that constitutes a PHY and a MAC
330 as described by the LFBs like EtherPHYCop, EtherMACIn, and
331 EtherMACOut.
333 IP packets emanating from port LFBs are then processed by a
334 validation LFB before being further forwarded to the next LFB. After
335 the validation process the packet is passed to an LFB where IP
336 forwarding decision is made. In the IP Forwarding LFBs, a Longest
337 Prefix Match LFB is used to look up the destination information in a
338 packet and select a next hop index for sending the packet onward. A
339 next hop LFB uses the next hop index metadata to apply the proper
340 headers to the IP packets, and direct them to the proper egress.
341 Note that in the process of IP packets processing, in this document,
342 we are adhering to the weak-host model [RFC1122] since that is the
343 most usable model for a packet processing Network Element.
345 3.2. Overview of LFB Classes in the Library
347 It is critical to classify functional requirements into various
348 classes of LFBs and construct a typical but also flexible enough base
349 LFB library for various IP forwarding equipments.
351 3.2.1. LFB Design Choices
353 A few design principles were factored into choosing how the base LFBs
354 looked like. These are:
356 o if a function can be designed by either one LFB or two or more
357 LFBs with the same cost, the choice is to go with two or more LFBs
358 so as to provide more flexibility for implementers.
360 o when flexibility is not required, an LFB should take advantage of
361 its independence as much as possible and have minimal coupling
362 with other LFBs. The coupling may be from LFB attributes
363 definitions as well as physical implementations.
365 o unless there is a clear difference in functionality, similar
366 packet processing should not be represented as two or more
367 different LFBs. Or else, it may add extra burden on
368 implementation to achieve interoperability.
370 3.2.2. LFB Class Groupings
372 The document defines groups of LFBs for typical router function
373 requirements:
375 (1) A group of Ethernet processing LFBs are defined to abstract the
376 packet processing for Ethernet as the port media type. As the
377 most popular media type with rich processing features, Ethernet
378 media processing LFBs was a natural choice. Definitions for
379 processing of other port media types like POS or ATM may be
380 incorporated in the library in future version of the document or
381 in a future separate document. The following LFBs are defined
382 for Ethernet processing:
384 * EtherPHYCop (Section 5.1.1)
386 * EtherMACIn (Section 5.1.2)
388 * EtherClassifier (Section 5.1.3)
390 * EtherEncap (Section 5.1.4)
392 * EtherMACOut (Section 5.1.5)
394 (2) A group of LFBs are defined for IP packet validation process.
395 The following LFBs are defined for IP validation processing:
397 * IPv4Validator (Section 5.2.1)
399 * IPv6Validator (Section 5.2.2)
401 (3) A group of LFBs are defined to abstract IP forwarding process.
402 The following LFBs are defined for IP forwarding processing:
404 * IPv4UcastLPM (Section 5.3.1)
406 * IPv4NextHop (Section 5.3.2)
408 * IPv6UcastLPM (Section 5.3.3)
410 * IPv6NextHop (Section 5.3.4)
412 (4) A group of LFBs are defined to abstract the process for redirect
413 operation, i.e., data packet transmission between CE and FEs.
414 The following LFBs are defined for redirect processing:
416 * RedirectIn (Section 5.4.1)
418 * RedirectOut (Section 5.4.2)
420 (5) A group of LFBs are defined for abstracting some general purpose
421 packet processing. These processing processes are usually
422 general to many processing locations in an FE LFB topology. The
423 following LFBs are defined for redirect processing:
425 * BasicMetadataDispatch (Section 5.5.1)
427 * GenericScheduler (Section 5.5.2)
429 3.2.3. Sample LFB Class Application
431 Although Section 7 will present use cases for LFBs defined in this
432 document, this section shows a sample LFB class application in
433 advance so that readers can get a quick overlook of the LFB classes
434 with the usage.
436 Figure 1 shows the typical LFB processing path for an IPv4 unicast
437 forwarding case with Ethernet media interfaces. To focus on the IP
438 forwarding function, some inputs or outputs of LFBs in the figure
439 that are not related to the function are ignored. Section 7.1 will
440 describe the figure in details.
442 +-----+ +------+
443 | | | |
444 | |<---------------|Ether |<----------------------------+
445 | | |MACOut| |
446 | | | | |
447 |Ether| +------+ |
448 |PHY | |
449 |Cop | +---+ |
450 |#1 | +-----+ | |----->IPv6 Packets |
451 | | | | | | |
452 | | |Ether| | | IPv4 Packets |
453 | |->|MACIn|-->| |-+ +----+ |
454 +-----+ | | | | | | |---> Multicast Packets |
455 +-----+ +---+ | | | +-----+ +---+ |
456 Ether +->| |------->| | | | |
457 . Classifier| | |Unicast |IPv4 | | | |
458 . | | |Packets |Ucast|->| |--+ |
459 . | +----+ |LPM | | | | |
460 +---+ | IPv4 +-----+ +---+ | |
461 +-----+ | | | Validator IPv4 | |
462 | | | | | NextHop| |
463 +-----+ |Ether| | |-+ IPv4 Packets | |
464 | |->|MACIn|-->| | | |
465 | | | | | |----->IPv6 Packets | |
466 |Ether| +-----+ +---+ | |
467 |PHY | Ether +----+ | |
468 |Cop | Classifier | | +-------+ | |
469 |#n | +------+ | | |Ether | | |
470 | | | | | |<--|Encap |<-+ |
471 | | | |<------| | | | |
472 | |<---------------|Ether | ...| | +-------+ |
473 | | |MACOut| +---| | |
474 | | | | | +----+ |
475 +-----+ +------+ | BasicMetadataDispatch |
476 +-------------------------+
478 Figure 1: LFB use case for IPv4 forwarding
480 3.3. Document Structure
482 Base type definitions, including data types, packet frame types, and
483 metadata types are presented in advance for definitions of various
484 LFB classes. Section 4 (Base Types section) provides a description
485 on the base types used by this LFB library. To enable extensive use
486 of these base types by other LFB class definitions, the base type
487 definitions are provided as a separate library.
489 Within every group of LFB classes, a set of LFBs are defined for
490 individual function purposes. Section 5 (LFB Class Descriptions
491 section) provides text descriptions on the individual LFBs. Note
492 that for a complete definition of an LFB, a text description as well
493 as a XML definition is required.
495 LFB classes are finally defined by XML with specifications and schema
496 defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB
497 Definitions section) provides the complete XML definitions of the
498 base LFB classes library.
500 Section 7 provides several use cases on how some typical router
501 functions can be implemented using the base LFB library defined in
502 this document.
504 4. Base Types
506 The FE model [RFC5812] has specified predefined (built-in) atomic
507 data-types as below:
509 char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
510 string, byte[N], boolean, octetstring[N], float16, float32, float64.
512 Based on the atomic data types and with the use of type definition
513 elements in the FE model XML schema, new data types, packet frame
514 types, and metadata types can be defined.
516 To define a base LFB library for typical router functions, a set of
517 base data types, frame types, and metadata types should be defined.
518 This section provides a brief description of the base types and a
519 full XML definition of them as well.
521 The base type XML definitions are provided with a separate XML
522 library file named "BaseTypeLibrary". Users can refer to this
523 library by the statement:
525
527 4.1. Data Types
529 Data types defined in the base type library are categorized by types
530 of atomic, compound struct, and compound array.
532 4.1.1. Atomic
534 The following data types are defined as atomic data types and put in
535 the base type library:
537 Data Type Name Brief Description
538 -------------- -----------------
539 IPv4Addr IPv4 address
540 IPv6Addr IPv6 address
541 IEEEMAC IEEE MAC address
542 LANSpeedType Network speed values
543 DuplexType Duplex types
544 PortStatusValues The possible values of port status, used for
545 both administrative and operative status
546 VlanIDType The type of VLAN ID
547 VlanPriorityType The type of VLAN priority
548 SchdDisciplineType Scheduling discipline type
550 4.1.2. Compound struct
552 The following compound struct types are defined in the base type
553 library:
555 Data Type Name Brief Description
556 -------------- -----------------
557 EtherDispatchEntryType Entry type for Ethernet dispatch table
558 VlanInputTableEntryType Entry type for VLAN input table
559 EncapTableEntryType Entry type for Ethernet encapsulation table
560 MACInStatsType Statistics type for EtherMACIn LFB
561 MACOutStatsType Statistics type for EtherMACOut LFB
562 EtherClassifyStatsType Entry type for statistics table in
563 EtherClassifier LFB
564 IPv4PrefixInfoType Entry type for IPv4 prefix table
565 IPv6PrefixInfoType Entry type for IPv6 prefix table
566 IPv4NextHopInfoType Entry type for IPv4 next hop table
567 IPv6NextHopInfoType Entry type for IPv6 next hop table
568 IPv4ValidatorStatsType Statistics type in IPv4validator LFB
569 IPv6ValidatorStatsType Statistics type in IPv6validator LFB
570 IPv4UcastLPMStatsType Statistics type in IPv4Unicast LFB
571 IPv6UcastLPMStatsType Statistics type in IPv6Unicast LFB
572 QueueStatsType Entry type for queue depth table
573 MetadataDispatchType Entry type for metadata dispatch table
575 4.1.3. Compound array
577 Compound array types are mostly created based on compound struct
578 types for LFB table components. The following compound array types
579 are defined in this base type library:
581 Data Type Name Brief Description
582 -------------- -----------------
583 EtherClassifyStatsTableType Type for Ethernet classifier statistics
584 information table
585 EtherDispatchTableType Type for Ethernet dispatch table
586 VlanInputTableType Type for VLAN input table
587 EncapTableType Type for Ethernet encapsulation table
588 IPv4PrefixTableType Type for IPv4 prefix table
589 IPv6PrefixTableType Type for IPv6 prefix table
590 IPv4NextHopTableType Type for IPv4 next hop table
591 IPv6NextHopTableType Type for IPv6 next hop table
592 MetadataDispatchTableType Type for Metadata dispatch table
593 QueueStatsTableType Type for Queue depth table
595 4.2. Frame Types
597 According to FE model [RFC5812], frame types are used in LFB
598 definitions to define packet frame types both an LFB expects at its
599 input port and the LFB emits at its output port. The
600 element in the FE model is used to define a new frame type.
602 The following frame types are defined in the base type library:
604 Frame Name Brief Description
605 -------------- ----------------
606 EthernetII An Ethernet II frame
607 ARP An ARP packet
608 IPv4 An IPv4 packet
609 IPv6 An IPv6 packet
610 IPv4Unicast An IPv4 unicast packet
611 IPv4Multicast An IPv4 multicast packet
612 IPv6Unicast An IPv6 unicast packet
613 IPv6Multicast An IPv6 multicast packet
614 Arbitrary Any types of packet frames
616 4.3. MetaData Types
618 LFB Metadata is used to communicate per-packet state from one LFB to
619 another. The element in the FE model is used to define
620 a new metadata type.
622 The following metadata types are currently defined in the base type
623 library.
625 Metadata Name Metadata ID Brief Description
626 ------------ ---------- -------------
627 PHYPortID 1 The ingress physical port that the packet
628 arrived on
629 SrcMAC 2 Source MAC address of the packet
630 DstMAC 3 Destination MAC address of the packet
631 LogicalPortID 4 ID of a logical port for the packet
632 EtherType 5 The packet's Ethernet type
633 VlanID 6 The VLAN ID of the Ethernet packet
634 VlanPriority 7 The priority of the Ethernet packet
635 NexthopIPv4Addr 8 Nexthop IPv4 address the packet is sent to
636 NexthopIPv6Addr 9 Nexthop IPv6 address the packet is sent to
637 HopSelector 10 A search key the packet can use to look up
638 a nexthop table for next hop information
639 of the packet
640 ExceptionID 11 Indicating exception type of the packet
641 which is exceptional for some processing
642 ValidateErrorID 12 Indicating error type of the packet failed
643 some validation process
644 L3PortID 13 ID of L3 port
645 RedirectIndex 14 A metadata CE sends to RedirectIn LFB for
646 the associated packet to select output
647 port in the LFB group output "PktsOut"
648 MediaEncapInfoIndex 15 A search key the packet uses to look up a
649 media encapsulation table to select its
650 encapsulation media as well as followed
651 encapsulation LFB
653 4.4. XML for Base Type Library
655
656
659
660
661 EthernetAll
662 All kinds of Ethernet frame
663
664
665 EthernetII
666 An Ethernet II frame
667
668
669 ARP
670 An arp packet
671
672
673 IPv4
674 An IPv4 packet
675
676
677 IPv6
678 An IPv6 packet
679
680
681 IPv4Unicast
682 An IPv4 unicast packet
683
684
685 IPv4Multicast
686 An IPv4 multicast packet
687
688
689 IPv6Unicast
690 An IPv6 unicast packet
691
692
693 IPv6Multicast
694 An IPv6 multicast packet
695
696
697 Arbitrary
698 Any types of packet frames
699
700
701
702
703 IPv4Addr
704 IPv4 address
705 byte[4]
706
707
708 IPv6Addr
709 IPv6 address
710 byte[16]
711
712
713 IEEEMAC
714 IEEE MAC address.
715 byte[6]
716
717
718 LANSpeedType
719 Network speed values
720
721 uint32
722
723
724 LAN_SPEED_10M
725 10M Ethernet
726
727
728 LAN_SPEED_100M
729 100M Ethernet
730
731
732 LAN_SPEED_1G
733 1000M Ethernet
734
735
736 LAN_SPEED_10G
737 10G Ethernet
738
739
740 LAN_SPEED_AUTO
741 LAN speed auto
742
743
744
745
746
747 DuplexType
748 Duplex types
749
750 uint32
751
752
753 Auto
754 Auto negotitation.
755
756
757 Half-duplex
758 port negotitation half duplex
759
760
761 Full-duplex
762 port negotitation full duplex
763
764
765
766
767
768 PortStatusValues
769 The possible values of port status, used for both
770 administrative and operative status.
771
772 uchar
773
774
775 Disabled
776 the port is operatively disabled.
777
778
779 UP
780 the port is up.
781
782
783 Down
784 The port is down.
785
786
787
788
789
790 MACInStatsType
791 Statistics type in EtherMACIn LFB.
792
793
794 NumPacketsReceived
795 The number of packets received.
796 uint64
797
798
799 NumPacketsDropped
800 The number of packets dropped.
801 uint64
802
803
804
805
806 MACOutStatsType
807 Statistics type in EtherMACOut LFB.
808
809
810 NumPacketsTransmitted
811 The number of packets transmitted.
812 uint64
813
814
815 NumPacketsDropped
816 The number of packets dropped.
817 uint64
818
819
820
821
822 EtherDispatchEntryType
823 Entry type for Ethernet dispatch table in
824 EtherClassifier LFB.
825
826
827 LogicalPortID
828 Logical port ID.
829 uint32
830
831
832 EtherType
833 The EtherType value in the Ether head.
834
835 uint32
836
837
838 LFBOutputSelectIndex
839 LFB Group output port index to select
840 downstream LFB port. Some possibilities of downstream
841 LFB instances are:
842 a) IPv4Validator
843 b) IPv6Validator
844 c) RedirectOut
845 d) etc
846 Note: LFBOutputSelectIndex is the FromPortIndex for
847 the port group "ClassifyOut" in the table LFBTopology
848 (of FEObject LFB) as defined for the EtherClassifier
849 LFB.
850 uint32
851
852
853
854
855 EtherDispatchTableType
856 Type for Ethernet dispatch table.This table is used
857 in EtherClassifier LFB. Every Ethernet packet can be
858 dispatched to the LFB output group ports according to the
859 logical port ID.
860
861 EtherDispatchEntryType
862
863
864
865 VlanIDType
866 The type of VLAN ID
867
868 uint16
869
870
871
872
873
874
875 VlanPriorityType
876 The type of VLAN priority.
877
878 uchar
879
880
881
882
883
884
885 VlanInputTableEntryType
886 Entry type for VLAN input table in EtherClassifier
887 LFB.
888
889
890 IncomingPortID
891 The incoming port ID.
892 uint32
893
894
895 VlanID
896 Vlan ID.
897 VlanIDType
898
899
900 LogicalPortID
901 logical port ID.
902 uint32
903
904
905
906
907 VlanInputTableType
908 Type for VLAN input table.This table is used
909 in EtherClassifier LFB. Every Ethernet packet can get a new
910 LogicalPortID according to the IncomingPortID and VlanID.
911
912
913 VlanInputTableEntryType
914
915
916
917 EtherClassifyStatsType
918 Entry type for statistics table in EtherClassifier
919 LFB.
920
921
922 EtherType
923 The EtherType value
924 uint32
925
926
927 PacketsNum
928 Packets number
929 uint64
930
931
932
933
934 EtherClassifyStatsTableType
935 Type for Ethernet classifier statistics
936 information table in EtherClassifier LFB.
937
938 EtherClassifyStatsType
939
940
941
942 IPv4ValidatorStatsType
943 Statistics type in IPv4validator LFB.
944
945
946 badHeaderPkts
947 Number of bad header packets.
948 uint64
949
950
951 badTotalLengthPkts
952 Number of bad total length packets.
953 uint64
954
955
956 badTTLPkts
957 Number of bad TTL packets.
958 uint64
959
960
961 badChecksumPkts
962 Number of bad checksum packets.
963 uint64
964
965
966
967
968 IPv6ValidatorStatsType
969 Statistics type in IPv6validator LFB.
970
971
972 badHeaderPkts
973 Number of bad header packets.
974 uint64
975
976
977 badTotalLengthPkts
978 Number of bad total length packets.
979 uint64
980
981
982 badHopLimitPkts
983 Number of bad Hop limit packets.
984 uint64
985
986
987
988
989 IPv4PrefixInfoType
990 Entry type for IPv4 prefix table.
991
992
993 IPv4Address
994 An IPv4 Address
995 IPv4Addr
996
997
998 Prefixlen
999 The prefix length
1000
1001 uchar
1002
1003
1004
1005
1006
1007
1008 HopSelector
1009 HopSelector is the nexthop ID which points to
1010 the nexthop table
1011 uint32
1012
1013
1014 ECMPFlag
1015 An ECMP Flag for this route
1016
1017 boolean
1018
1019
1020 False
1021 This route does not have multiple
1022 nexthops.
1023
1024
1025 True
1026 This route has multiple nexthops.
1027
1028
1029
1030
1031
1032
1033 DefaultRouteFlag
1034 A default route flag.
1035
1036 boolean
1037
1038
1039 False
1040 This is not a default route.
1041
1042
1043
1044 True
1045 This route is a default route.
1046
1047
1048
1049
1050
1051
1052
1053
1054 IPv4PrefixTableType
1055 Type for IPv4 prefix table. This table is currently
1056 used in IPv4UcastLPM LFB. The LFB uses the destination IPv4
1057 address of every input packet as search key to look up this
1058 table in order extract a next hop selector.
1059
1060 IPv4PrefixInfoType
1061
1062
1063
1064 IPv4UcastLPMStatsType
1065 Statistics type in IPv4Unicast LFB.
1066
1067
1068 InRcvdPkts
1069 The total number of input packets received.
1070
1071 uint64
1072
1073
1074 FwdPkts
1075 IPv4 packets forwarded by this LFB
1076 uint64
1077
1078
1079 NoRoutePkts
1080 The number of IP datagrams discarded because
1081 no route could be found.
1082 uint64
1083
1084
1085
1086
1087 IPv6PrefixInfoType
1088 Entry type for IPv6 prefix table.
1089
1090
1091 IPv6Address
1092 An IPv6 Address
1093 IPv6Addr
1094
1095
1096 Prefixlen
1097 The prefix length
1098
1099 uchar
1100
1101
1102
1103
1105
1106
1107 HopSelector
1108 HopSelector is the nexthop ID which points
1109 to the nexthop table
1110 uint32
1111
1112
1113 ECMPFlag
1114 An ECMP Flag for this route
1115
1116 boolean
1117
1118
1119 False
1120 This route does not have multiple
1121 nexthops.
1122
1123
1124 True
1125 This route has multiple nexthops.
1126
1127
1128
1129
1130
1131
1132 DefaultRouteFlag
1133 A Default Route Flag.
1134
1135 boolean
1136
1137
1138 False
1139 This is not a default route.
1140
1141
1142
1143 True
1144 This route is a default route.
1145
1146
1147
1148
1149
1150
1151
1152
1153 IPv6PrefixTableType
1154 Type for IPv6 prefix table.This table is currently
1155 used in IPv6UcastLPM LFB. The LFB uses the destination IPv6
1156 address of every input packet as search key to look up this
1157 table in order extract a next hop selector.
1158
1159 IPv6PrefixInfoType
1160
1161
1162
1163 IPv6UcastLPMStatsType
1164 Statistics type in IPv6Unicast LFB.
1165
1166
1167 InRcvdPkts
1168 The total number of input packets
1169 received
1170 uint64
1171
1172
1173 FwdPkts
1174 IPv6 packets forwarded by this LFB
1175 uint64
1176
1177
1178 NoRoutePkts
1179 The number of IP datagrams discarded because
1180 no route could be found.
1181 uint64
1182
1183
1184
1185
1186 IPv4NextHopInfoType
1187 Entry type for IPv4 next hop table.
1188
1189
1190 L3PortID
1191 The ID of the Logical/physical Output Port
1192 that we pass onto the downstream LFB instance. This
1193 ID indicates what port to the neighbor is as defined
1194 by L3.
1195 uint32
1196
1197
1198 MTU
1199 Maximum Transmission Unit for out going port.
1200 It is for desciding whether the packet need
1201 fragmentation
1202 uint32
1203
1204
1205 NextHopIPAddr
1206 Next Hop IPv4 Address
1207 IPv4Addr
1208
1209
1210 MediaEncapInfoIndex
1211 The index we pass onto the downstream LFB
1212 instance. This index is used to lookup a table
1213 (typically media encapsulatation related) further
1214 downstream.
1215 uint32
1216
1217
1218 LFBOutputSelectIndex
1219 LFB Group output port index to select
1220 downstream LFB port. Some possibilities of downstream
1221 LFB instances are:
1222 a) EtherEncap
1223 b) Other type of media LFB
1224 c) A metadata Dispatcher
1225 d) A redirect LFB
1226 e) etc
1227 Note: LFBOutputSelectIndex is the FromPortIndex for
1228 the port group "SuccessOut" in the table LFBTopology
1229 (of FEObject LFB) as defined for the IPv4NextHop LFB.
1230
1231 uint32
1232
1233
1234
1235
1236 IPv4NextHopTableType
1237 Type for IPv4 next hop table. This table is used
1238 in IPv4NextHop LFB. The LFB uses metadata "HopSelector"
1239 received to match the array index to get the next hop
1240 information.
1241
1242 IPv4NextHopInfoType
1243
1244
1245
1246 IPv6NextHopInfoType
1247 Entry type for IPv6 next hop table.
1248
1249
1250 L3PortID
1251 The ID of the Logical/physical Output Port
1252 that we pass onto the downstream LFB instance. This
1253 ID indicates what port to the neighbor is as defined
1254 by L3.
1255 uint32
1256
1257
1258 MTU
1259 Maximum Transmission Unit for out going port.
1260 It is for desciding whether the packet need
1261 fragmentation.
1262 uint32
1263
1264
1265 NextHopIPAddr
1266 Next Hop IPv6 Address
1267 IPv6Addr
1268
1269
1270 MediaEncapInfoIndex
1271 The index we pass onto the downstream LFB
1272 instance. This index is used to lookup a table
1273 (typically media encapsulatation related) further
1274 downstream.
1275 uint32
1276
1277
1278 LFBOutputSelectIndex
1279 LFB Group output port index to select
1280 downstream LFB port. Some possibilities of downstream
1281 LFB instances are:
1282 a) EtherEncap
1283 b) Other type of media LFB
1284 c) A metadata Dispatcher
1285 d) A redirect LFB
1286 e) etc
1287 Note: LFBOutputSelectIndex is the FromPortIndex for
1288 the port group "SuccessOut" in the table LFBTopology
1289 (of FEObject LFB) as defined for the IPv6NextHop LFB.
1290
1291 uint32
1292
1293
1294
1295
1296 IPv6NextHopTableType
1297 Type for IPv6 next hop table. This table is used
1298 in IPv6NextHop LFB. The LFB uses metadata "HopSelector"
1299 received to match the array index to get the next hop
1300 information.
1301
1302 IPv6NextHopInfoType
1303
1304
1305
1306 EncapTableEntryType
1307 Entry type for Ethernet encapsulation table in
1308 EtherEncap LFB.
1309
1310
1311 DstMac
1312 Ethernet Mac of the Neighbor
1313 IEEEMAC
1314
1315
1316 SrcMac
1317 Source MAC used in encapsulation
1318 IEEEMAC
1319
1320
1321 VlanID
1322 VLAN ID.
1323 VlanIDType
1324
1325
1326 L2PortID
1327 Output logical L2 port ID.
1328 uint32
1329
1330
1331
1332
1333 EncapTableType
1334 Type for Ethernet encapsulation table. This
1335 table is used in EtherEncap LFB. The LFB uses the metadata
1336 "MediaEncapInfoIndex " received to get the encapsulation
1337 information.
1338
1339 EncapTableEntryType
1340
1341
1342
1343 MetadataDispatchType
1344 Entry type for Metadata dispatch table in
1345 BasicMetadataDispatch LFB.
1346
1347
1348 MetadataValue
1349 metadata value.
1350 uint32
1351
1352
1353 OutputIndex
1354 group output port index.
1355 uint32
1356
1357
1358
1359
1360 MetadataDispatchTableType
1361 Type for Metadata dispatch table. This table is used
1362 in BasicMetadataDispatch LFB. The LFB uses MetadataValue to
1363 get the LFB group output port index.
1364
1365 MetadataDispatchType
1366
1367 MetadataValue
1368
1369
1370
1371
1372 SchdDisciplineType
1373 Scheduling discipline type.
1374
1375 uint32
1376
1377
1378 RR
1379 Round Robin scheduler.
1380
1381
1382
1383
1384
1385 QueueStatsType
1386 Entry type for queue statistics table in
1387 GenericScheduler LFB.
1388
1389
1390 QueueID
1391 Queue ID
1392 uint32
1394
1395
1396 QueueDepthInPackets
1397 the Queue Depth when the depth units
1398 are packets.
1399 uint32
1400
1401
1402 QueueDepthInBytes
1403 the Queue Depth when the depth units
1404 are bytes.
1405 uint32
1406
1407
1408
1409
1410 QueueStatsTableType
1411 Type for Queue statistics table in GenericScheduler
1412 LFB.
1413
1414 QueueDepthType
1415
1416
1417
1418
1419
1420 PHYPortID
1421 The physical port ID that a packet has entered.
1422
1423 1
1424 uint32
1425
1426
1427 SrcMAC
1428 Source MAC address of the packet.
1429 2
1430 IEEEMAC
1431
1432
1433 DstMAC
1434 Destination MAC address of the packet.
1435 3
1436 IEEEMAC
1437
1438
1439 LogicalPortID
1440 ID of a logical port for the packet.
1441 4
1442 uint32
1443
1444
1445 EtherType
1446 Indicating the Ethernet type of the Ethernet packet.
1447
1448 5
1449 uint32
1450
1451
1452 VlanID
1453 The Vlan ID of the Ethernet packet.
1454 6
1455 VlanIDType
1456
1457
1458 VlanPriority
1459 The priority of the Ethernet packet.
1460 7
1461 VlanPriorityType
1462
1463
1464 NexthopIPv4Addr
1465 Nexthop IPv4 address the packet is sent to.
1466
1467 8
1468 IPv4Addr
1469
1470
1471 NexthopIPv6Addr
1472 Nexthop IPv6 address the packet is sent to.
1473
1474 9
1475 IPv6Addr
1476
1477
1478 HopSelector
1479 A search key the packet can use to look up a nexthop
1480 table for next hop information of the packet.
1481 10
1482 uint32
1483
1484
1485 ExceptionID
1486 Indicating exception type of the packet which is
1487 exceptional for some processing.
1488 11
1489
1490 uint32
1491
1492
1493 AnyUnrecognizedExceptionCase
1494 any unrecognized exception case.
1495
1496
1497 ClassifyNoMatching
1498 There is no matching when classifying the
1499 packet in EtherClassifier LFB.
1500
1501
1502 MediaEncapInfoIndexInvalid
1503 The MediaEncapInfoIndex value of the
1504 packet is invalid and can not be allocated in the
1505 EncapTable.
1506
1507
1508 EncapTableLookupFailed
1509 The packet failed lookup of the EncapTable
1510 table even though the MediaEncapInfoIndex is valid.
1511
1512
1513
1514 BadTTL
1515 Packet with expired TTL.
1516
1517
1518 IPv4HeaderLengthMismatch
1519 Packet with header length more than 5
1520 words.
1521
1522
1523 RouterAlertOptions
1524 Packet IP head include Router Alert
1525 options.
1526
1527
1528 IPv6HopLimitZero
1529 Packet with Hop Limit zero
1530
1531
1532 IPv6NextHeaderHBH
1533 Packet with next header set to Hop-by-Hop
1534
1535
1536
1537 SrcAddressExecption
1538 Packet with exceptional source address.
1539
1540
1541
1542 DstAddressExecption
1543 Packet with exceptional destination
1544 address
1545
1546
1547 LPMLookupFailed
1548 The packet failed the LPM lookup of the
1549 prefix table.
1550
1551
1552 HopSelectorInvalid
1553 The HopSelector for the packet is invalid.
1554
1555
1556
1557 NextHopLookupFailed
1558 The packet failed lookup of the NextHop
1559 table even though the HopSelector is valid.
1560
1561
1562
1563 FragRequired
1564 The MTU for outgoing interface is less
1565 than the packet size.
1566
1567
1568 MetadataNoMatching
1569 There is no matching when looking up the
1570 metadata dispatch table.
1571
1572
1573
1574
1575
1576 ValidateErrorID
1577 Indicating error type of the packet failed some
1578 validation process.
1579 12
1580
1581 uint32
1582
1583
1584 AnyUnrecognizedValidateErrorCase
1585 Any unrecognized validate error case.
1587
1588
1589
1590 InvalidIPv4PacketSize
1591 Packet size reported is less than 20
1592 bytes.
1593
1594
1595 NotIPv4Packet
1596 Packet is not IP version 4.
1597
1598
1599 InvalidIPv4HeaderLengthSize
1600 Packet with header length less than
1601 5 words.
1602
1603
1604 InvalidIPv4LengthFieldSize
1605 Packet with total length field less than
1606 20 bytes.
1607
1608
1609 InvalidIPv4Checksum
1610 Packet with invalid checksum.
1611
1612
1613 InvalidIPv4SrcAddr
1614 Packet with invalid source address.
1615
1616
1617
1618 InvalidIPv4DstAddr
1619 Packet with source address 0.
1620
1621
1622 InvalidIPv6PacketSize
1623 Packet size reported is less than 40
1624 bytes.
1625
1626
1627 NotIPv6Packet
1628 Packet is not IP version 6.
1629
1630
1631 InvalidIPv6SrcAddr
1632 Packet with invalid source address.
1633
1634
1635
1636 InvalidIPv6DstAddr
1637 Packet with invalid destination address.
1638
1639
1640
1641
1642
1643
1644 L3PortID
1645 ID of L3 port. See the definition in
1646 IPv4NextHopInfoType.
1647 13
1648 uint32
1649
1650
1651 RedirectIndex
1652 metadata CE sends to RedirectIn LFB for the
1653 associated packet to select output port in the LFB group
1654 output "PktsOut".
1655 14
1656 uint32
1657
1658
1659 MediaEncapInfoIndex
1660 A search key the packet uses to look up a media
1661 encapsulation table to select its encapsulation media as
1662 well as followed encapsulation LFB.
1663 15
1664 uint32
1665
1666
1667
1669 5. LFB Class Description
1671 According to ForCES specifications, LFB (Logical Function Block) is a
1672 well defined, logically separable functional block that resides in an
1673 FE, and is a functionally accurate abstraction of the FE's processing
1674 capabilities. An LFB Class (or type) is a template that represents a
1675 fine-grained, logically separable aspect of FE processing. Most LFBs
1676 are related to packet processing in the data path. LFB classes are
1677 the basic building blocks of the FE model. Note that [RFC5810] has
1678 already defined an 'FE Protocol LFB' which is a logical entity in
1679 each FE to control the ForCES protocol. [RFC5812] has already
1680 defined an 'FE Object LFB'. Information like the FE Name, FE ID, FE
1681 State, LFB Topology in the FE are represented in this LFB.
1683 As specified in Section 3.1, this document focuses on the base LFB
1684 library for implementing typical router functions, especially for IP
1685 forwarding functions. As a result, LFB classes in the library are
1686 all base LFBs to implement router forwarding.
1688 In this section, the terms "upstream LFB" and "downstream LFB" are
1689 used. These are used relative to an LFB to an LFB that is being
1690 described. An "upstream LFB" is one whose output ports are connected
1691 to input ports of the LFB under consideration such that output
1692 (typically packets with metadata) can be sent from the "upstream LFB"
1693 to the LFB under consideration. Similarly, a "downstream LFB" whose
1694 input ports are connected to output ports of the LFB under
1695 consideration such that the LFB under consideration can send
1696 information to the "downstream LFB". Note that in some rare
1697 topologies, an LFB may be both upstream and downstream relative to
1698 another LFB.
1700 Also note that, as a default provision of [RFC5812], in FE model, all
1701 metadata produced by upstream LFBs will pass through all downstream
1702 LFBs by default without being specified by input port or output port.
1703 Only those metadata that will be used (consumed) by an LFB will be
1704 explicitly marked in input of the LFB as expected metadata. For
1705 instance, in downstream LFBs of a physical layer LFB, even there is
1706 no specific metadata expected, metadata like PHYPortID produced by
1707 the physical layer LFB will always pass through all downstream LFBs
1708 regardless of whether the metadata has been expected by the LFBs or
1709 not.
1711 5.1. Ethernet Processing LFBs
1713 As the most popular physical and data link layer protocols, Ethernet
1714 is widely deployed. It becomes a basic requirement for a router to
1715 be able to process various Ethernet data packets.
1717 Note that there exist different versions of Ethernet formats, like
1718 Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP.
1719 There also exist varieties of LAN techniques based on Ethernet, like
1720 various VLANs, MACinMAC, etc. Ethernet processing LFBs defined here
1721 are intended to be able to cope with all these variations of Ethernet
1722 technology.
1724 There are also various types of Ethernet physical interface media.
1725 Among them, copper and fiber media may be the most popular ones. As
1726 a base LFB definition and a starting point, the document only defines
1727 an Ethernet physical LFB with copper media. For other media
1728 interfaces, specific LFBs may be defined in the future versions of
1729 the library.
1731 5.1.1. EtherPHYCop
1733 EtherPHYCop LFB abstracts an Ethernet interface physical layer with
1734 media limited to copper.
1736 5.1.1.1. Data Handling
1738 This LFB is the interface to the Ethernet physical media. The LFB
1739 handles ethernet frames coming in from or going out of the FE.
1740 Ethernet frames sent and received cover all packets encapsulated with
1741 different versions of Ethernet protocols, like Ethernet V2, 802.3
1742 RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets
1743 encapsulated with varieties of LAN techniques based on Ethernet, like
1744 various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll
1745 frame type has been introduced.
1747 Ethernet frames are received from the physical media port and passed
1748 downstream to LFBs such as EtherMACIn via a singleton output known as
1749 "EtherPHYOut". A 'PHYPortID' metadata, to indicate which physical
1750 port the frame came into from the external world, is passed along
1751 with the frame.
1753 Ethernet packets are received by this LFB from upstream LFBs such as
1754 EtherMacOut LFBs via the singleton input known as "EtherPHYIn" before
1755 being sent out onto the external world.
1757 5.1.1.2. Components
1759 The AdminStatus component is defined for CE to administratively
1760 manage the status of the LFB. The CE may administratively startup or
1761 shutdown the LFB by changing the value of AdminStatus. The default
1762 value is set to 'Down'.
1764 An OperStatus component captures the physical port operational
1765 status. A PHYPortStatusChanged event is defined so the LFB can
1766 report to the CE whenever there is an operational status change of
1767 the physical port.
1769 The PHYPortID component is a unique identification for a physical
1770 port. It is defined as 'read-only' by CE. Its value is enumerated
1771 by FE. The component will be used to produce a 'PHYPortID' metadata
1772 at the LFB output and to associate it to every Ethernet packet this
1773 LFB receives. The metadata will be handed to downstream LFBs for
1774 them to use the PHYPortID.
1776 A group of components are defined for link speed management. The
1777 AdminLinkSpeed is for CE to configure link speed for the port and the
1778 OperLinkSpeed is for CE to query the actual link speed in operation.
1779 The default value for the AdminLinkSpeed is set to auto-negotiation
1780 mode.
1782 A group of components are defined for duplex mode management. The
1783 AdminDuplexMode is for CE to configure proper duplex mode for the
1784 port and the OperDuplexMode is for CE to query the actual duplex mode
1785 in operation. The default value for the AdminDuplexMode is set to
1786 auto-negotiation mode.
1788 A CarrierStatus component captures the status of the carrier and
1789 specifies whether the port link is operationally up. The default
1790 value for the CarrierStatus is 'false'.
1792 5.1.1.3. Capabilities
1794 The capability information for this LFB includes the link speeds that
1795 are supported by the FE (SupportedLinkSpeed) as well as the supported
1796 duplex modes (SupportedDuplexMode).
1798 5.1.1.4. Events
1800 Several events are generated. There is an event for changes in the
1801 status of the physical port (PhyPortStatusChanged). Such an event
1802 will notify that the physical port status has been changed and the
1803 report will include the new status of the physical port.
1805 Another event captures changes in the operational link speed
1806 (LinkSpeedChanged). Such an event will notify the CE that the
1807 operational speed has been changed and the report will include the
1808 new negotiated operational speed.
1810 A final event captures changes in the duplex mode
1811 (DuplexModeChanged). Such an event will notify the CE that the
1812 duplex mode has been changed and the report will include the new
1813 negotiated duplex mode.
1815 5.1.2. EtherMACIn
1817 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer.
1818 This LFB describes Ethernet processing functions like MAC address
1819 locality check, deciding if the Ethernet packets should be bridged,
1820 providing Ethernet layer flow control, etc.
1822 5.1.2.1. Data Handling
1824 The LFB is expected to receive all types of Ethernet packets, via a
1825 singleton input known as "EtherPktsIn", which are usually output from
1826 some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside
1827 with a metadata indicating the physical port ID that the packet
1828 arrived on.
1830 The LFB is defined with two separate singleton outputs. All Output
1831 packets are emitted in the original ethernet format received at the
1832 physical port, unchanged, and cover all types of ethernet types.
1834 The first singleton output is known as "NormalPathOut". It usually
1835 outputs Ethernet packets to some LFB like an EtherClassifier LFB for
1836 further L3 forwarding process alongside with a PHYPortID metadata
1837 indicating which physical port the packet came from.
1839 The second singleton output is known as "L2BridgingPathOut".
1840 Although the LFB library this document defines is basically to meet
1841 typical router functions, it will attempt to be forward compatible
1842 with future router functions. The "L2BridgingPathOut" is defined to
1843 meet the requirement that L2 bridging functions may be optionally
1844 supported simultaneously with L3 processing and some L2 bridging LFBs
1845 that may be defined in the future. If the FE supports L2 bridging,
1846 the CE can enable or disable it by means of a "L2BridgingPathEnable"
1847 component in the FE. If it is enabled, by also instantiating some L2
1848 bridging LFB instances following the L2BridgingPathOut, FEs are
1849 expected to fulfill L2 bridging functions. L2BridgingPathOut will
1850 output packets exactly the same as that in the NormalPathOut output.
1852 This LFB can be set to work in a Promiscuous Mode, allowing all
1853 packets to pass through the LFB without being dropped. Otherwise, a
1854 locality check will be performed based on the local MAC addresses.
1855 All packets that do not pass through the locality check will be
1856 dropped.
1858 This LFB participates in Ethernet flow control in cooperation with
1859 EtherMACOut LFB. This document does not go into the details of how
1860 this is implemented; the reader may refer to some relevant
1861 references. This document also does not describe how the buffers
1862 which induce the flow control messages behave - it is assumed that
1863 such artifacts exist and describing them is out of scope in this
1864 document.
1866 5.1.2.2. Components
1868 The AdminStatus component is defined for the CE to administratively
1869 manage the status of the LFB. The CE may administratively startup or
1870 shutdown the LFB by changing the value of AdminStatus. The default
1871 value is set to 'Down'.
1873 The LocalMACAddresses component specifies the local MAC addresses
1874 based on which locality checks will be made. This component is an
1875 array of MAC addresses, and of 'read-write' access permission.
1877 An L2BridgingPathEnable component captures whether the LFB is set to
1878 work as a L2 bridge. An FE that does not support bridging will
1879 internally set this flag to false, and additionally set the flag
1880 property as read-only. The default value for is 'false'.
1882 The PromiscuousMode component specifies whether the LFB is set to
1883 work as in a promiscuous mode. The default value for is 'false'.
1885 The TxFlowControl component defines whether the LFB is performing
1886 flow control on sending packets. The default value for is 'false'.
1888 The RxFlowControl component defines whether the LFB is performing
1889 flow control on receiving packets. The default value for is 'false'.
1891 A struct component, MACInStats, defines a set of statistics for this
1892 LFB, including the number of received packets and the number of
1893 dropped packets.
1895 5.1.2.3. Capabilities
1897 This LFB does not have a list of capabilities.
1899 5.1.2.4. Events
1901 This LFB does not have any events specified.
1903 5.1.3. EtherClassifier
1905 EtherClassifier LFB abstracts the process to decapsulate Ethernet
1906 packets and then classify them.
1908 5.1.3.1. Data Handling
1910 This LFB describes the process of decapsulating Ethernet packets and
1911 classifying them into various network layer data packets according to
1912 information included in the Ethernet packets headers.
1914 The LFB is expected to receive all types of Ethernet packets, via a
1915 singleton input known as "EtherPktsIn", which are usually output from
1916 an upstream LFB like EtherMACIn LFB. This input is also capable of
1917 multiplexing to allow for multiple upstream LFBs being connected.
1918 For instance, when L2 bridging function is enabled in EtherMACIn LFB,
1919 some L2 bridging LFBs may be applied. In this case, some Ethernet
1920 packets after L2 processing may have to be input to EtherClassifier
1921 LFB for classification, while simultaneously packets directly output
1922 from EtherMACIn may also need to input to this LFB. This input is
1923 capable of handling such a case. Usually, all expected Ethernet
1924 Packets will be associated with a PHYPortID metadata, indicating the
1925 physical port the packet comes from. In some cases, for instance,
1926 like in a MACinMAC case, a LogicalPortID metadata may be expected to
1927 associate with the Ethernet packet to further indicate which logical
1928 port the Ethernet packet belongs to. Note that PHYPortID metadata is
1929 always expected while LogicalPortID metadata is optionally expected.
1931 Two output LFB ports are defined.
1933 The first output is a group output port known as "ClassifyOut".
1934 Types of network layer protocol packets are output to instances of
1935 the port group. Because there may be various types of protocol
1936 packets at the output ports, the produced output frame is defined as
1937 arbitrary for the purpose of wide extensibility in the future.
1938 Metadata to be carried along with the packet data is produced at this
1939 LFB for consumption by downstream LFBs. The metadata passed
1940 downstream includes PHYPortID, as well as information on Ethernet
1941 type, source MAC address, destination MAC address and the logical
1942 port ID. .If the original packet is a VLAN packet and contains a VLAN
1943 ID and a VLAN priority value, then the VLAN ID and the VLAN priority
1944 value are also carried downstream as metadata. As a result, the VLAN
1945 ID and priority metadata are defined with the availability of
1946 "conditional".
1948 The second output is a singleton output port known as "ExceptionOut",
1949 which will output packets for which the data processing failed, along
1950 with an additional ExceptionID metadata to indicate what caused the
1951 exception. Currently defined exception types include:
1953 o There is no matching when classifying the packet.
1955 Usually the exception out port may point to no where, indicating
1956 packets with exceptions are dropped, while in some cases, the output
1957 may be pointed to the path to the CE for further processing,
1958 depending on individual implementations.
1960 5.1.3.2. Components
1962 An EtherDispatchTable array component is defined in the LFB to
1963 dispatch every Ethernet packet to the output group according to the
1964 logical port ID assigned by the VlanInputTable to the packet and the
1965 Ethernet type in the Ethernet packet header. Each row of the array
1966 is a struct containing a Logical Port ID, an EtherType and an Output
1967 Index. With the CE configuring the dispatch table, the LFB can be
1968 expected to classify various network layer protocol type packets and
1969 output them at different output ports. It is expected that the LFB
1970 classify packets according to protocols like IPv4, IPv6, MPLS, ARP,
1971 ND, etc.
1973 A VlanInputTable array component is defined in the LFB to classify
1974 VLAN Ethernet packets. Each row of the array is a struct containing
1975 an Incoming Port ID, a VLAN ID and a Logical Port ID. According to
1976 IEEE VLAN specifications, all Ethernet packets can be recognized as
1977 VLAN types by defining that if there is no VLAN encapsulation in a
1978 packet, a case with VLAN tag 0 is considered. Every input packet is
1979 assigned with a new LogicalPortID according to the packet incoming
1980 port ID and the VLAN ID. A packet incoming port ID is defined as a
1981 logical port ID if a logical port ID is associated with the packet,
1982 or a physical port ID if no logical port ID associated. The VLAN ID
1983 is exactly the VLAN ID in the packet if it is a VLAN packet, or 0 if
1984 it is not. Note that a logical port ID of a packet may be rewritten
1985 with a new one by the VlanInputTable processing.
1987 Note that the logical port ID and physical port ID mentioned above
1988 are all originally configured by CE, and are globally effective
1989 within a ForCES NE (Network Element). To distinguish a physical port
1990 ID from a logical port ID in the incoming port ID field of the
1991 VlanInputTable, physical port ID and logical port ID must be assigned
1992 with separate number spaces.
1994 An array component, EtherClassifyStats, defines a set of statistics
1995 for this LFB, measuring the number of packets per EtherType. Each
1996 row of the array is a struct containing an EtherType and a Packet
1997 number.
1999 5.1.3.3. Capabilities
2001 This LFB does not have a list of capabilities.
2003 5.1.3.4. Events
2005 This LFB has no events specified.
2007 5.1.4. EtherEncap
2009 The EtherEncap LFB abstracts the process to replace or attach
2010 appropriate Ethernet headers to the packet.
2012 5.1.4.1. Data Handling
2014 This LFB abstracts the process of encapsulating Ethernet headers onto
2015 received packets. The encapsulation is based on passed metadata.
2017 The LFB is expected to receive IPv4 and IPv6 packets, via a singleton
2018 input port known as "EncapIn" which may be connected to an upstream
2019 LFB like an IPv4NextHop, an IPv6NextHop, BasicMetadataDispatch, or
2020 any LFB which requires to output packets for Ethernet encapsulation.
2021 The LFB always expects from upstream LFBs the MediaEncapInfoIndex
2022 metadata which is used as a search key to lookup the Encapsulation
2023 Table. An input packet may also optionally receive a VLAN priority
2024 metadata, indicating that the packet is originally with a priority
2025 value. The priority value will be loaded back to the packet when
2026 encapsulating. The optional VLAN priority metadata is defined with a
2027 default value 0.
2029 Two singleton output LFB ports are defined.
2031 The first singleton output known as "SuccessOut". Upon a successful
2032 table lookup, the destination and source MAC addresses, and the
2033 logical media port (L2PortID) are found in the matching table entry.
2034 The CE may set the VlanID in case VLANs are used. By default the
2035 table entry for VlanID of 0 is used as per IEEE rules. Whatever the
2036 value of VlanID is, if the input metadata VlanPriority is non-zero,
2037 the packet will have a VLAN tag. If the VlanPriority and the VlanID
2038 are all zero, there is no VLAN tag to this packet. After replacing
2039 or attaching the appropriate Ethernet headers to the packet is
2040 complete, the packet is passed out on the "SuccessOut" LFB port to a
2041 downstream LFB instance alongside with the L2PortID.
2043 The second singleton output known as "ExceptionOut", which will
2044 output packets for which the table lookup fails, along with an
2045 additional ExceptionID metadata. Currently defined exception types
2046 only include the following case:
2048 o The MediaEncapInfoIndex value of the packet is invalid and can not
2049 be allocated in the EncapTable.
2051 o The packet failed lookup of the EncapTable table even though the
2052 MediaEncapInfoIndex is valid.
2054 The upstream LFB may be programmed by the CE to pass along a
2055 MediaEncapInfoIndex that does not exist in the EncapTable. That is
2056 to allow for resolution of the L2 headers, if needed, to be made at
2057 the L2 encapsulation level in this case (Ethernet) via ARP, or ND (or
2058 other methods depending on the link layer technology) when a table
2059 miss occurs.
2061 For neighbor L2 header resolution(table miss exception), the
2062 processing LFB may pass this packet to the CE via the redirect LFB or
2063 FE software or another LFB instance for further resolution. In such
2064 a case the metadata NexthopIPv4Addr or NexthopIPv6Addr generated by
2065 Nexthop LFB is also passed to the exception handling. Such an IP
2066 address could be used to do activities such as ARP or ND by the
2067 handler it is passed to.
2069 The result of the L2 resolution is to update the EncapTable as well
2070 as the Nexthop LFB so subsequent packets do not fail EncapTable
2071 lookup. The EtherEncap LFB does not make any assumptions of how the
2072 EncapTable is updated by the CE (or whether ARP/ND is used
2073 dynamically or static maps exist).
2075 Downstream LFB instances could be either an EtherMACOut type or a
2076 BasicMetadataDispatch type. If the final packet L2 processing is
2077 possible to be on per-media-port basis or resides on a different FE
2078 or in cases where L2 header resolution is needed, then the model
2079 makes sense to use a BasicMetadataDispatch LFB to fanout to different
2080 LFB instances. If there is a direct egress port point, then the
2081 model makes sense to have a downstream LFB instance being an
2082 EtherMACOut.
2084 5.1.4.2. Components
2086 This LFB has only one component named EncapTable which is defined as
2087 an array. Each row of the array is a struct containing the
2088 destination MAC address, the source MAC address, the VLAN ID with a
2089 default value of zero and the output logical L2 port ID.
2091 5.1.4.3. Capabilities
2093 This LFB does not have a list of capabilities.
2095 5.1.4.4. Events
2097 This LFB does not have any events specified.
2099 5.1.5. EtherMACOut
2101 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer.
2102 This LFB describes Ethernet packet output process. Ethernet output
2103 functions are closely related to Ethernet input functions, therefore
2104 many components defined in this LFB are as aliases of EtherMACIn LFB
2105 components.
2107 5.1.5.1. Data Handling
2109 The LFB is expected to receive all types of Ethernet packets, via a
2110 singleton input known as "EtherPktsIn", which are usually output from
2111 an Ethernet encapsulation LFB, alongside with a metadata indicating
2112 the physical port ID that the packet will go through.
2114 The LFB is defined with a singleton output. All Output packets are
2115 in Ethernet format, possibly with various Ethernet types, alongside
2116 with a metadata indicating the physical port ID the packet is to go
2117 through. This output links to a downstream LFB that is usually an
2118 Ethernet physical LFB like EtherPHYcop LFB.
2120 This LFB participates in Ethernet flow control in cooperation with
2121 EtherMACIn LFB. This document does not go into the details of how
2122 this is implemented; the reader may refer to some relevant
2123 references. This document also does not describe how the buffers
2124 which induce the flow control messages behave - it is assumed that
2125 such artifacts exist and describing them is out of scope in this
2126 document.
2128 Note that as a base definition, functions like multiple virtual MAC
2129 layers are not supported in this LFB version. It may be supported in
2130 the future by defining a subclass or a new version of this LFB.
2132 5.1.5.2. Components
2134 The AdminStatus component is defined for CE to administratively
2135 manage the status of the LFB. The CE may administratively startup or
2136 shutdown the LFB by changing the value of AdminStatus. The default
2137 value is set to 'Down'. Note that this component is defined as an
2138 alias of the AdminStatus component in the EtherMACIn LFB. This
2139 infers that an EtherMACOut LFB usually coexists with an EtherMACIn
2140 LFB, both of which share the same administrative status management by
2141 CE. Alias properties as defined in the ForCES FE model [RFC5812]
2142 will be used by CE to declare the target component this alias refers,
2143 which include the target LFB class and instance IDs as well as the
2144 path to the target component.
2146 The MTU component defines the maximum transmission unit.
2148 The TxFlowControl component defines whether the LFB is performing
2149 flow control on sending packets. The default value for is 'false'.
2150 Note that this component is defined as an alias of TxFlowControl
2151 component in the EtherMACIn LFB.
2153 The RxFlowControl component defines whether the LFB is performing
2154 flow control on receiving packets. The default value for is 'false'.
2155 Note that this component is defined as an alias of RxFlowControl
2156 component in the EtherMACIn LFB.
2158 A struct component, MACOutStats, defines a set of statistics for this
2159 LFB, including the number of transmitted packets and the number of
2160 dropped packets.
2162 5.1.5.3. Capabilities
2164 This LFB does not have a list of capabilities.
2166 5.1.5.4. Events
2168 This LFB does not have any events specified.
2170 5.2. IP Packet Validation LFBs
2172 The LFBs are defined to abstract IP packet validation process. An
2173 IPv4Validator LFB is specifically for IPv4 protocol validation and an
2174 IPv6Validator LFB for IPv6.
2176 5.2.1. IPv4Validator
2178 The IPv4Validator LFB performs IPv4 packets validation according to
2179 [RFC5812].
2181 5.2.1.1. Data Handling
2183 This LFB performs IPv4 validation according to [RFC5812]. The IPv4
2184 packet will be output to the corresponding LFB port the indication
2185 whether the packet is unicast, multicast or whether an exception has
2186 occurred or the validation failed.
2188 This LFB always expects, as input, packets which have been indicated
2189 as IPv4 packets by an upstream LFB, like an EtherClassifier LFB.
2190 There is no specific metadata expected by the input of the LFB.
2192 Four output LFB ports are defined.
2194 All validated IPv4 unicast packets will be output at the singleton
2195 port known as "IPv4UnicastOut". All validated IPv4 multicast packets
2196 will be output at the singleton port known as "IPv4MulticastOut"
2197 port.
2199 A singleton port known as "ExceptionOut" is defined to output packets
2200 which have been validated as exception packets. An exception ID
2201 metadata is produced to indicate what has caused the exception. An
2202 exception case is the case when a packet needs further processing
2203 before being normally forwarded. Currently defined exception types
2204 include:
2206 o Packet with expired TTL
2208 o Packet with header length more than 5 words
2210 o Packet IP head including Router Alert options
2212 o Packet with exceptional source address
2214 o Packet with exceptional destination address
2216 Note that although TTL is checked in this LFB for validity,
2217 operations like TTL decrement are made by the downstream forwarding
2218 LFB.
2220 The final singleton port known as "FailOut" is defined for all
2221 packets which have errors and failed the validation process. An
2222 error case is the case when a packet is unable to be further
2223 processed nor forwarded except being dropped. An error ID is
2224 associated a packet to indicate the failure reason. Currently
2225 defined failure reasons include:
2227 o Packet with size reported less than 20 bytes
2229 o Packet with version is not IPv4
2231 o Packet with header length less than 5 words
2233 o Packet with total length field less than 20 bytes
2235 o Packet with invalid checksum
2237 o Packet with invalid source address
2239 o Packet with invalid destination address
2241 5.2.1.2. Components
2243 This LFB has only one struct component, the
2244 IPv4ValidatorStatisticsType, which defines a set of statistics for
2245 validation process, including the number of bad header packets, the
2246 number of bad total length packets, the number of bad TTL packets,
2247 and the number of bad checksum packets.
2249 5.2.1.3. Capabilities
2251 This LFB does not have a list of capabilities
2253 5.2.1.4. Events
2255 This LFB does not have any events specified.
2257 5.2.2. IPv6Validator
2259 The IPv6Validator LFB performs IPv6 packets validation according to
2260 [RFC2460].
2262 5.2.2.1. Data Handling
2264 This LFB performs IPv6 validation according to [RFC2460]. Then the
2265 IPv6 packet will be output to the corresponding port regarding of the
2266 validation result, whether the packet is a unicast or a multicast
2267 one, an exception has occurred or the validation failed.
2269 This LFB always expects, as input, packets which have been indicated
2270 as IPv6 packets by an upstream LFB, like an EtherClassifier LFB.
2271 There is no specific metadata expected by the input of the LFB.
2273 Similar to the IPv4validator LFB, IPv6Validator LFB has also defined
2274 four output ports to emit packets with various validation results.
2276 All validated IPv6 unicast packets will be output at the singleton
2277 port known as "IPv6UnicastOut". All validated IPv6 multicast packets
2278 will be output at the singleton port known as "IPv6MulticastOut"
2279 port. There is no metadata produced at this LFB.
2281 A singleton port known as "ExceptionOut" is defined to output packets
2282 which have been validated as exception packets. An exception case is
2283 the case when a packet needs further processing before being normally
2284 forwarded. An exception ID metadata is produced to indicate what
2285 caused the exception. Currently defined exception types include:
2287 o Packet with hop limit to zero
2289 o Packet with next header set to Hop-by-Hop
2291 o Packet with exceptional source address
2293 o Packet with exceptional destination address
2295 The final singleton port known as "FailOut" is defined for all
2296 packets which have errors and failed the validation process. An
2297 error case is the case when a packet is unable to be further
2298 processed nor forwarded except being dropped. A validate error ID is
2299 associated to every failed packet to indicate the reason. Currently
2300 defined reasons include:
2302 o Packet with size reported less than 40 bytes
2304 o Packet with not IPv6 version
2306 o Packet with invalid source address
2308 o Packet with invalid destination address
2310 Note that in the base type library, definitions for exception ID and
2311 validate error ID metadata are applied to both IPv4Validator and
2312 IPv6Validator LFBs, i.e., the two LFBs share the same medadata
2313 definition, with different ID assignment inside.
2315 5.2.2.2. Components
2317 This LFB has only one struct component, the
2318 IPv6ValidatorStatisticsType, which defines a set of statistics for
2319 validation process, including the number of bad header packets, the
2320 number of bad total length packets, and the number of bad hop limit
2321 packets.
2323 5.2.2.3. Capabilities
2325 This LFB does not have a list of capabilities
2327 5.2.2.4. Events
2329 This LFB does not have any events specified.
2331 5.3. IP Forwarding LFBs
2333 IP Forwarding LFBs are specifically defined to abstract the IP
2334 forwarding processes. As definitions for a base LFB library, this
2335 document restricts its LFB definition scope only to IP unicast
2336 forwarding. IP multicast may be defined in future documents.
2338 A typical IP unicast forwarding job is usually realized by looking up
2339 the forwarding information table to find next hop information, and
2340 then based on the next hop information, forwarding packets to
2341 specific physical output ports. It usually takes two steps to do so,
2342 firstly to look up a forwarding information table by means of Longest
2343 Prefix Matching(LPM) rule to find a next hop index, then to use the
2344 index as a search key to look up a next hop information table to find
2345 enough information to submit packets to output ports. This document
2346 abstracts the forwarding processes mainly based on the two steps
2347 model. However, there actually exists other models, like one which
2348 may only have a forwarding information base that have conjoined next
2349 hop information together with forwarding information. In this case,
2350 if ForCES technology is to be applied, some translation work will
2351 have to be done in the FE to translate attributes defined by this
2352 document into attributes related to the implementation.
2354 Based on the IP forwarding abstraction, two kind of typical IP
2355 unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next
2356 hop application LFB. They are further distinguished by IPv4 and IPv6
2357 protocols.
2359 5.3.1. IPv4UcastLPM
2361 The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match
2362 (LPM) process.
2364 This LFB also provides facilities to support users to implement
2365 equal-cost multi-path routing (ECMP) or reverse path forwarding
2366 (RPF). However, this LFB itself does not provide ECMP or RPF. To
2367 fully implement ECMP or RPF, additional specific LFBs, like a
2368 specific ECMP LFB or an RPF LFB, will have to be defined. This work
2369 may be done in the future version of the document.
2371 5.3.1.1. Data Handling
2373 This LFB performs the IPv4 unicast LPM table looking up. It always
2374 expects as input IPv4 unicast packets from one singleton input known
2375 as "PktsIn". Then the LFB uses the destination IPv4 address of every
2376 packet as search key to look up the IPv4 prefix table and generate a
2377 hop selector as the matching result. The hop selector is passed as
2378 packet metadata to downstream LFBs, and will usually be used there as
2379 a search index to find more next hop information.
2381 Three singleton output LFB ports are defined.
2383 The first singleton output known as "NormalOut" outputs IPv4 unicast
2384 packets that succeed the LPM lookup and (got a hop selector). The
2385 hop selector is associated with the packet as a metadata. Downstream
2386 from the LPM LFB is usually a next hop application LFB, like an
2387 IPv4NextHop LFB.
2389 The second singleton output known as "ECMPOut" is defined to provide
2390 support for users wishing to implement ECMP.
2392 An ECMP flag is defined in the LPM table to enable the LFB to support
2393 ECMP. When a table entry is created with the flag set true, it
2394 indicates this table entry is for ECMP only. A packet, which has
2395 passed through this prefix lookup, will always output from "ECMPOut"
2396 output port, with the hop selector being its lookup result. The
2397 output will usually directly go to a downstream ECMP processing LFB,
2398 where the hop selector can usually further generate optimized one or
2399 multiple next hop routes by use of ECMP algorithms.
2401 A default route flag is defined in the LPM table to enable the LFB to
2402 support a default route as well as loose RPF. When this flag is set
2403 true, the table entry is identified a default route which also
2404 implies that the route is forbidden for RPF. If a user wants to
2405 implement RPF on FE, a specific RPF LFB will have to be defined. In
2406 such RPF LFB, a component can be defined as an alias of the prefix
2407 table component of this LFB as described below.
2409 The final singleton output is known as "ExceptionOut" and is defined
2410 to allow exception packets to output here, along with an ExceptionID
2411 metadata to indicate what caused the exception. Currently defined
2412 exception types include:
2414 o The packet failed the LPM lookup of the prefix table.
2416 The upstream LFB of this LFB is usually IPv4Validator LFB. If RPF is
2417 to be adopted, the upstream can be an RPF LFB, when defined.
2419 The downstream LFB is usually IPv4NextHop LFB. If ECMP is adopted,
2420 the downstream can be an ECMP LFB, when defined.
2422 5.3.1.2. Components
2424 This LFB has two components.
2426 The IPv4PrefixTable component is defined as an array component of the
2427 LFB. Each row of the array contains an IPv4 address, a Prefix
2428 length, a Hop Selector, an ECMP flag and a Default Route flag. The
2429 LFB uses the destination IPv4 address of every input packet as search
2430 key to look up this table in order extract a next hop selector. The
2431 ECMP flag is for the LFB to support ECMP. The default route flag is
2432 for the LFB to support a default route and for loose RPF.
2434 The IPv4UcastLPMStats component is a struct component which collects
2435 statistics information, including the total number of input packets
2436 received, the IPv4 packets forwarded by this LFB and the number of IP
2437 datagrams discarded due to no route found.
2439 5.3.1.3. Capabilities
2441 This LFB does not have a list of capabilities
2443 5.3.1.4. Events
2445 This LFB does not have any events specified.
2447 5.3.2. IPv4NextHop
2449 This LFB abstracts the process of selecting ipv4 next hop action.
2451 5.3.2.1. Data Handling
2453 The LFB abstracts the process of next hop information application to
2454 IPv4 packets. It receives an IPv4 packet with an associated next hop
2455 identifier (HopSelector), and uses the identifier as a table index to
2456 look up a next hop table to find an appropriate LFB output port.
2458 The LFB is expected to receive unicast IPv4 packets, via a singleton
2459 input known as "PcktsIn" along with a HopSelector metadata which is
2460 used as a table index to lookup the NextHop table. The data
2461 processing involves the forwarding TTL decrement and IP checksum
2462 recalculation.
2464 Two output LFB ports are defined.
2466 The first output is a group output port known as "SuccessOut". On
2467 successful data processing the packet is sent out an LFB-port from
2468 within the LFB port group as selected by the LFBOutputSelectIndex
2469 value of the matched table entry. The packet is sent to a downstream
2470 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
2472 The second output is a singleton output port known as "ExceptionOut",
2473 which will output packets for which the data processing failed, along
2474 with an additional ExceptionID metadata to indicate what caused the
2475 exception. Currently defined exception types include:
2477 o The HopSelector for the packet is invalid.
2479 o The packet failed lookup of the NextHop table even though the
2480 HopSelector is valid.
2482 o The MTU for outgoing interface is less than the packet size.
2484 Downstream LFB instances could be either a BasicMetadataDispatch type
2485 (Section 5.5.1), used to fanout to different LFB instances or a media
2486 encapsulation related type, such as an EtherEncap type or a
2487 RedirectOut type(Section 5.4.2). For example, if there are Ethernet
2488 and other tunnel Encapsulation, then a BasicMetadataDispatch LFB can
2489 use the L3PortID metadata (Section 5.3.2.2) to dispatch packets to
2490 different Encapsulator.
2492 5.3.2.2. Components
2494 This LFB has only one component named IPv4NextHopTable which is
2495 defined as an array. The HopSelector received is used to match the
2496 array index of IPv4NextHopTable to find out a row of the table as the
2497 next hop information result. Each row of the array is a struct
2498 containing:
2500 o The L3PortID, which is the ID of the Logical Output Port that is
2501 passed onto the downstream LFB instance. This ID indicates what
2502 port to the neighbor is as defined by L3. Usually this ID is used
2503 for the NextHop LFB to distinguish packets that need different L2
2504 encapsulating. For instance, some packets may require general
2505 Ethernet encapsulation while others may require various types of
2506 tunnel encapsulations. In such case, different L3PortIDs are
2507 assigned to the packets and are as metadata passed to downstream
2508 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be
2509 applied as the downstream LFB so as to dispatch packets to
2510 different encapsulation LFB insatnces according to the L3PortIDs.
2512 o MTU, the Maximum Transmission Unit for the outgoing port.
2514 o NextHopIPAddr, the IPv4 next hop Address.
2516 o MediaEncapInfoIndex, the index we pass onto the downstream
2517 encapsulation LFB instance and that is used there as a search key
2518 to lookup a table (typically media encapsulation related) for
2519 further encapsulation information. Note that an encapsulation LFB
2520 instance may not directly follow the NextHop LFB, but the index is
2521 passed as a metadata associated, as such an encapsulation LFB
2522 instance even further downstream to the NextHop LFB can still use
2523 the index. In some cases, depending on implementation, the CE may
2524 set the MediaEncapInfoIndex passed downstream to a value that will
2525 fail lookup when it gets to a target encapsulation LFB; such a
2526 lookup failure at that point is an indication that further
2527 resolution is needed. For an example of this approach refer to
2528 Section 7.2 which talks about ARP and mentions this approach.
2530 o LFBOutputSelectIndex, the LFB Group output port index to select
2531 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's
2532 table LFBTopology (See [RFC5812]) component FromPortIndex
2533 corresponding to the port group mapping FromLFBID as IPv4NextHop
2534 LFB instance.
2536 5.3.2.3. Capabilities
2538 This LFB does not have a list of capabilities
2540 5.3.2.4. Events
2542 This LFB does not have any events specified.
2544 5.3.3. IPv6UcastLPM
2546 The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match
2547 (LPM) process. The definition of this LFB is similar to the
2548 IPv4UcastLPM LFB except that all IP addresses refer to IPv6
2549 addresses.
2551 This LFB also provides facilities to support users to implement
2552 equal-cost multi-path routing (ECMP) or reverse path forwarding
2553 (RPF). However, this LFB itself does not provide ECMP or RPF. To
2554 fully implement ECMP or RPF, additional specific LFBs, like a
2555 specific ECMP LFB or an RPF LFB, will have to be defined. This work
2556 may be done in the future version of the document.
2558 5.3.3.1. Data Handling
2560 This LFB performs the IPv6 unicast LPM table look up. It always
2561 expects as input IPv6 unicast packets from one singleton input known
2562 as "PktsIn". The destination IPv6 address of an incoming packet is
2563 used as search key to look up the IPv6 prefix table and generate a
2564 hop selector. This hop selector result is associated to the packet
2565 as a metadata and sent to downstream LFBs, and will usually be used
2566 in downstream LFBs as a search key to find more next hop information.
2568 Three singleton output LFB ports are defined.
2570 The first singleton output known as "NormalOut" outputs IPv6 unicast
2571 packets that succeed the LPM lookup (and got a hop selector). The
2572 hop selector is associated with the packet as a metadata. Downstream
2573 from the LPM LFB is usually a next hop application LFB, like an
2574 IPv6NextHop LFB.
2576 The second singleton output known as "ECMPOut" is defined to provide
2577 support for users wishing to implement ECMP.
2579 An ECMP flag is defined in the LPM table to enable the LFB to support
2580 ECMP. When a table entry is created with the flag set true, it
2581 indicates this table entry is for ECMP only. A packet, which has
2582 passed through this prefix lookup, will always output from "ECMPOut"
2583 output port, with the hop selector being its lookup result. The
2584 output will usually directly go to a downstream ECMP processing LFB,
2585 where the hop selector can usually further generate optimized one or
2586 multiple next hop routes by use of ECMP algorithms.
2588 A default route flag is defined in the LPM table to enable the LFB to
2589 support a default route as well as loose RPF. When this flag is set
2590 true, the table entry is identified a default route which also
2591 implies that the route is forbidden for RPF.
2593 If a user wants to implement RPF on FE, a specific RPF LFB will have
2594 to be defined. In such RPF LFB, a component can be defined as an
2595 alias of the prefix table component of this LFB as described below.
2597 The final singleton output is known as "ExceptionOut" and is defined
2598 to allow exception packets to output here, along with an ExceptionID
2599 metadata to indicate what caused the exception. Currently defined
2600 exception types include:
2602 o The packet failed the LPM lookup of the prefix table.
2604 The upstream LFB of this LFB is usually IPv6Validator LFB. If RPF is
2605 to be adopted, the upstream can be an RPF LFB, when defined.
2607 The downstream LFB is usually an IPv6NextHop LFB. If ECMP is
2608 adopted, the downstream can be an ECMP LFB, when defined.
2610 5.3.3.2. Components
2612 This LFB has two components.
2614 The IPv6PrefixTable component is defined as an array component of the
2615 LFB. Each row of the array contains an IPv6 address, a Prefix
2616 length, a Hop Selector, an ECMP flag and a Default Route flag. The
2617 ECMP flag is so the LFB can support ECMP. The default route flag is
2618 for the LFB to support a default route and for loose RPF as described
2619 earlier.
2621 The IPv6UcastLPMStats component is a struct component which collects
2622 statistics information, including the total number of input packets
2623 received, the IPv6 packets forwarded by this LFB and the number of IP
2624 datagrams discarded due to no route found.
2626 5.3.3.3. Capabilities
2628 This LFB does not have a list of capabilities
2630 5.3.3.4. Events
2632 This LFB does not have any events specified.
2634 5.3.4. IPv6NextHop
2636 This LFB abstracts the process of selecting IPv6 next hop action.
2638 5.3.4.1. Data Handling
2640 The LFB abstracts the process of next hop information application to
2641 IPv6 packets. It receives an IPv6 packet with an associated next hop
2642 identifier (HopSelector), and uses the identifier to look up a next
2643 hop table to find an appropriate output port from the LFB.
2645 The LFB is expected to receive unicast IPv6 packets, via a singleton
2646 input known as "PcktsIn" along with a HopSelector metadata which is
2647 used as a table index to lookup the NextHop table.
2649 Two output LFB ports are defined.
2651 The first output is a group output port known as "SuccessOut". On
2652 successful data processing the packet is sent out an LFB port from
2653 within the LFB port group as selected by the LFBOutputSelectIndex
2654 value of the matched table entry. The packet is sent to a downstream
2655 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
2657 The second output is a singleton output port known as "ExceptionOut",
2658 which will output packets for which the data processing failed, along
2659 with an additional ExceptionID metadata to indicate what caused the
2660 exception. Currently defined exception types include:
2662 o The HopSelector for the packet is invalid.
2664 o The packet failed lookup of the NextHop table even though the
2665 HopSelector is valid.
2667 o The MTU for outgoing interface is less than the packet size.
2669 Downstream LFB instances could be either a BasicMetadataDispatch
2670 type, used to fanout to different LFB instances or a media
2671 encapsulatation related type, such as an EtherEncap type or a
2672 RedirectOut type. For example, when the downstream LFB is
2673 BasicMetadataDispatch, and there exist Ethernet and other tunnel
2674 Encapsulation downstream from BasicMetadataDispatch, then the
2675 BasicMetadataDispatch LFB can use the L3PortID metadata (See section
2676 below) to dispatch packets to the different Encapsulator LFBs.
2678 5.3.4.2. Components
2680 This LFB has only one component named IPv6NextHopTable which is
2681 defined as an array. The array index of IPv6NextHopTable is used for
2682 a HopSelector to find out a row of the table as the next hop
2683 information. Each row of the array is a struct containing:
2685 o The L3PortID, which is the ID of the Logical Output Port that is
2686 passed onto the downstream LFB instance. This ID indicates what
2687 port to the neighbor is as defined by L3. Usually this ID is used
2688 for the NextHop LFB to distinguish packets that need different L2
2689 encapsulating. For instance, some packets may require general
2690 Ethernet encapsulation while others may require various types of
2691 tunnel encapsulations. In such case, different L3PortIDs are
2692 assigned to the packets and are as metadata passed to downstream
2693 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be
2694 applied as the downstream LFB so as to dispatch packets to
2695 different encapsulation LFB instances according to the L3PortIDs.
2697 o MTU, the Maximum Transmission Unit for the outgoing port.
2699 o NextHopIPAddr, the IPv6 next hop Address.
2701 o MediaEncapInfoIndex, the index we pass onto the downstream
2702 encapsulation LFB instance and that is used there as a search key
2703 to lookup a table (typically media encapsulation related) for
2704 further encapsulation information. Note that an encapsulation LFB
2705 instance may not directly follow the NextHop LFB, but the index is
2706 passed as a metadata associated, as such an encapsulation LFB
2707 instance even further downstream to the NextHop LFB can still use
2708 the index. In some cases, depending on implementation, the CE may
2709 set the MediaEncapInfoIndex passed downstream to a value that will
2710 fail lookup when it gets to a target encapsulation LFB; such a
2711 lookup failure at that point is an indication that further
2712 resolution is needed. For an example of this approach refer to
2713 Section 7.2 which talks about ARP and mentions this approach.
2715 o LFBOutputSelectIndex, the LFB Group output port index to select
2716 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's
2717 table LFBTopology (See [RFC5812]) component FromPortIndex
2718 corresponding to the port group mapping FromLFBID as IPv4NextHop
2719 LFB instance.
2721 5.3.4.3. Capabilities
2723 This LFB does not have a list of capabilities
2725 5.3.4.4. Events
2727 This LFB does not have any events specified.
2729 5.4. Redirect LFBs
2731 Redirect LFBs abstract data packets transportation process between CE
2732 and FE. Some packets output from some LFBs may have to be delivered
2733 to CE for further processing, and some packets generated by CE may
2734 have to be delivered to FE and further to some specific LFBs for data
2735 path processing. According to [RFC5810], data packets and their
2736 associated metadata are encapsulated in ForCES redirect message for
2737 transportation between CE and FE. We define two LFBs to abstract the
2738 process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an LFB
2739 topology of an FE, only one RedirectIn LFB instance and one
2740 RedirectOut LFB instance exist.
2742 5.4.1. RedirectIn
2744 RedirectIn LFB abstracts the process for the CE to inject data
2745 packets into the FE data path.
2747 5.4.1.1. Data Handling
2749 A RedirectIn LFB abstracts the process for the CE to inject data
2750 packets into the FE LFB topology so as to input data packets into FE
2751 data paths. From LFB topology point of view, the RedirectIn LFB acts
2752 as a source point for data packets coming from CE, therefore
2753 RedirectIn LFB is defined with a single output LFB port (and no input
2754 LFB port).
2756 The single output port of RedirectIn LFB is defined as a group output
2757 type, with the name of "PktsOut". Packets produced by this output
2758 will have arbitrary frame types decided by the CE which generated the
2759 packets. Possible frames may include IPv4, IPv6, or ARP protocol
2760 packets. The CE may associate some metadata to indicate the frame
2761 types and may also associate other metadata to indicate various
2762 information on the packets. Among them, there MUST exist a
2763 'RedirectIndex' metadata, which is an integer acting as an index.
2764 When the CE transmits the metadata along with the packet to a
2765 RedirectIn LFB, the LFB will read the RedirectIndex metadata and
2766 output the packet to one of its group output port instance, whose
2767 port index is indicated by this metadata. Any other metadata, in
2768 addition to 'RedirectIndex', will be passed untouched along the
2769 packet delivered by the CE to downstream LFB. This means the
2770 'RedirectIndex' metadata from CE will be "consumed" by the RedirectIn
2771 LFB and will not be passed to downstream LFB. Note that, a packet
2772 from CE without a 'RedirectIndex' metadata associated will be dropped
2773 by the LFB.
2775 5.4.1.2. Components
2777 There are no components defined for the current version of RedirectIn
2778 LFB.
2780 5.4.1.3. Capabilities
2782 This LFB does not have a list of capabilities
2784 5.4.1.4. Events
2786 This LFB does not have any events specified.
2788 5.4.2. RedirectOut
2790 RedirectOut LFB abstracts the process for LFBs in the FE to deliver
2791 data packets to the CE.
2793 5.4.2.1. Data Handling
2795 A RedirectOut LFB abstracts the process for LFBs in the FE to deliver
2796 data packets to the CE. From the LFB's topology point of view, the
2797 RedirectOut LFB acts as a sink point for data packets going to the
2798 CE, therefore RedirectOut LFB is defined with a single input LFB port
2799 (and no output LFB port).
2801 The RedirectOut LFB has only one singleton input known as "PktsIn",
2802 but is capable of receiving packets from multiple LFBs by
2803 multiplexing this input. The input expects any kind of frame type
2804 therefore the frame type has been specified as arbitrary, and also
2805 all types of metadata are expected. All associated metadata produced
2806 (but not consumed) by previous processed LFBs should be delivered to
2807 CE via the ForCES protocol redirect message [RFC5810]. The CE can
2808 decide on how to process the redirected packet by referencing the
2809 associated metadata. As an example, a packet could be redirected by
2810 the FE to the CE because the EtherEncap LFB is not able to resolve L2
2811 information. The metadata "ExceptionID", created by the EtherEncap
2812 LFB is passed along with the packet and should be sufficient for the
2813 CE to do the necessary processing and resolve the L2 entry required.
2815 5.4.2.2. Components
2817 There are no components defined for the current version of
2818 RedirectOut LFB.
2820 5.4.2.3. Capabilities
2822 This LFB does not have a list of capabilities
2824 5.4.2.4. Events
2826 This LFB does not have any events specified.
2828 5.5. General Purpose LFBs
2830 5.5.1. BasicMetadataDispatch
2832 The BasicMetadataDispatch LFB is defined to abstract the process in
2833 which a packet is dispatched to some output path based on its
2834 associated metadata value.
2836 5.5.1.1. Data Handling
2838 The BasicMetadataDispatch has only one singleton input known as
2839 "PktsIn". Every input packet should be associated with a metadata
2840 that will be used by the LFB to do the dispatch. This LFB contains a
2841 Metadata ID component a dispatch table named MetadataDispatchTable,
2842 all configured by the CE. The Metadata ID specifies which metadata
2843 is to be used for dispatching packets. The MetadataDispatchTable
2844 contains entries of a Metadata value and an OutputIndex, specifying
2845 that the packet with the metadata value must go out from the LFB
2846 group output port instance with the OutputIndex.
2848 Two output LFB ports are defined.
2850 The first output is a group output port known as "PktsOut". A packet
2851 with its associated metadata having found an OutputIndex by
2852 successfully looking up the dispatch table will be output to the
2853 group port instance with the corresponding index.
2855 The second output is a singleton output port known as "ExceptionOut",
2856 which will output packets for which the data processing failed, along
2857 with an additional ExceptionID metadata to indicate what caused the
2858 exception. Currently defined exception types include:
2860 o There is no matching when looking up the metadata dispatch table.
2862 As an example, if the CE decides to dispatch packets according to a
2863 physical port ID (PHYPortID), the CE may set the ID of PHYPortID
2864 metadata to the LFB first. Moreover, the CE also sets the PHYPortID
2865 actual values (the metadata values) and assigned OutputIndex for the
2866 values to the dispatch table in the LFB. When a packet arrives, a
2867 PHYPortID metadata is found associated with the packet, the metadata
2868 value is further used as a key to look up the dispatch table to find
2869 out an output port instance for the packet.
2871 Currently the BasicMetadataDispatch LFB only allows the metadata
2872 value of the dispatch table entry be 32-bits integer. A metadata
2873 with other types of value is not supported in this version. A more
2874 complex metadata dispatch LFB may be defined in future version of the
2875 library. In that LFB, multiple tuples of metadata with more value
2876 types supported may be used to dispatch packets.
2878 5.5.1.2. Components
2880 This LFB has two components. One component is MetadataID and the
2881 other is MetadataDispatchTable. Each row entry of the dispatch table
2882 is a struct containing metadata value and the OutputIndex. Note that
2883 currently, the metadata value is only allowed to be 32-bits integer.
2884 The metadata value is also defined as a content key for the table.
2885 The concept of content key is a searching key for tables which is
2886 defined in the ForCES FE Model [RFC5812]. See this document and also
2887 the ForCES Protocol [RFC5810] for more details on the definition and
2888 use of a content key.
2890 5.5.1.3. Capabilities
2892 This LFB does not have a list of capabilities
2894 5.5.1.4. Events
2896 This LFB does not have any events specified.
2898 5.5.2. GenericScheduler
2900 This is a preliminary generic scheduler LFB for abstracting a simple
2901 scheduling process.
2903 5.5.2.1. Data Handling
2905 There exist various kinds of scheduling strategies with various
2906 implementations. As a base LFB library, this document only defines a
2907 preliminary generic scheduler LFB for abstracting a simple scheduling
2908 process. Users may use this LFB as a basic scheduler LFB to further
2909 construct more complex scheduler LFBs by means of inheritance as
2910 described in [RFC5812].
2912 Packets of any arbitrary frame type are received via a group input
2913 known as "PktsIn" with no additional metadata expected. This group
2914 input is capable of multiple input port instances. Each port
2915 instance may be connected to different upstream LFB output.
2917 Multiple queues reside at the input side, with every input LFB port
2918 instance connected to one queue. Every queue is marked with a queue
2919 ID, and the queue ID is exactly the same as the index of
2920 corresponding input port instance. Scheduling disciplines are
2921 applied to all queues and also all packets in the queues.
2923 Scheduled packets are output from a singleton output port of the LFB
2924 knows as "PktsOut" with no corresponding metadata.
2926 More complex scheduler LFBs may be defined with more complex
2927 scheduling disciplines by succeeding this LFB. For instance, a
2928 priority scheduler LFB may be defined by inheriting this LFB and
2929 defining a component to indicate priorities for all input queues.
2931 5.5.2.2. Components
2933 The QueueCount component is defined to specify the number of queues
2934 to be scheduled.
2936 The SchedulingDiscipline component is for the CE to specify a
2937 scheduling discipline to the LFB. Currently defined scheduling
2938 disciplines only include Round Robin (RR) strategy. The default
2939 scheduling discipline is RR then.
2941 The QueueStats component is defined to allow CE to query every queue
2942 status of the scheduler. It is an array component and each row of
2943 the array is a struct containing a queue ID. Currently defined queue
2944 status includes the queue depth in packets and the queue depth in
2945 bytes. Using the queue ID as the index, the CE can query every queue
2946 for its used length in unit of packets or bytes.
2948 5.5.2.3. Capabilities
2950 The following capability is currently defined for the
2951 GenericScheduler.
2953 o The queue length limit providing the storage ability for every
2954 queue.
2956 5.5.2.4. Events
2958 This LFB does not have any events specified.
2960 6. XML for LFB Library
2962
2963
2966
2967
2968
2969 EtherPHYCop
2970 The LFB describes an Ethernet port abstracted at
2971 physical layer.It limits its physical media to copper.
2972 Multiple virtual PHYs isn't supported in this LFB version.
2973
2974 1.0
2975
2976
2977 EtherPHYIn
2978 The input port of the EtherPHYCop LFB. It
2979 expects any kind of Ethernet frame.
2980
2981
2982 [EthernetAll]
2983
2984
2985
2986
2987
2988
2989 EtherPHYOut
2990 The output port of the EtherPHYCop LFB. It
2991 can produce any kind of Ethernet frame and along with
2992 the frame passes the ID of the Physical Port as
2993 metadata to be used by the next LFBs.
2994
2995
2996 [EthernetAll]
2997
2998
2999 [PHYPortID]
3000
3001
3002
3003
3004
3005
3006 PHYPortID
3007 The ID of the physical port that this LFB
3008 handles.
3009 uint32
3010
3011
3012 AdminStatus
3013 Admin status of the LFB
3014 PortStatusValues
3015 2
3016
3017
3018 OperStatus
3019 Operational status of the LFB.
3020 PortStatusValues
3021
3022
3023 AdminLinkSpeed
3024 The link speed that the admin has requested.
3025
3026 LANSpeedType
3027 LAN_SPEED_AUTO
3028
3029
3030 OperLinkSpeed
3031 The actual operational link speed.
3032 LANSpeedType
3033
3034
3035 AdminDuplexMode
3036 The duplex mode that the admin has requested.
3037
3038 DuplexType
3039 Auto
3040
3041
3042 OperDuplexMode
3043 The actual duplex mode.
3044 DuplexType
3045
3046
3047 CarrierStatus
3048 The status of the Carrier. Whether the port
3049 is linked with an operational connector.
3050 boolean
3051 false
3052
3053
3054
3055
3056 SupportedLinkSpeed
3057 Supported Link Speeds
3058
3059 LANSpeedType
3060
3061
3062
3063 SupportedDuplexMode
3064 Supported Duplex Modes
3065
3066 DuplexType
3067
3068
3069
3070
3071
3072 PHYPortStatusChanged
3073 When the status of the Physical port is
3074 changed,the LFB sends the new status.
3075
3076 OperStatus
3077
3078
3079
3080
3081 OperStatus
3082
3083
3084
3085
3086 LinkSpeedChanged
3087 When the operational speed of the link
3088 is changed, the LFB sends the new operational link
3089 speed.
3090
3091 OperLinkSpeed
3092
3093
3094
3095
3096 OperLinkSpeed
3097
3098
3099
3100
3101 DuplexModeChanged
3102 When the operational duplex mode
3103 is changed, the LFB sends the new operational mode.
3104
3105
3106 OperDuplexMode
3107
3108
3109
3110
3111 OperDuplexMode
3112
3113
3114
3115
3116
3117
3118 EtherMACIn
3119 An LFB abstracts an Ethernet port at MAC data link
3120 layer. It specifically describes Ethernet processing functions
3121 like MAC address locality check, deciding if the Ethernet
3122 packets should be bridged, provide Ethernet layer flow control,
3123 etc.Multiple virtual MACs isn't supported in this LFB
3124 version.
3125 1.0
3126
3127
3128 EtherPktsIn
3129 The input port of the EtherMACIn. It
3130 expects any kind of Ethernet frame.
3131
3132
3133 [EthernetAll]
3134
3135
3136 [PHYPortID]
3137
3138
3139
3140
3141
3142
3143 NormalPathOut
3144 The normal output port of the EtherMACIn.
3145 It can produce any kind of Ethernet frame and along
3146 with the frame passes the ID of the Physical Port as
3147 metadata to be used by the next LFBs.
3148
3149
3150 [EthernetAll]
3152
3153
3154 [PHYPortID]
3155
3156
3157
3158
3159 L2BridgingPathOut
3160 The Bridging Output Port of the EtherMACIn.
3161 It can produce any kind of Ethernet frame and along
3162 with the frame passes the ID of the Physical Port as
3163 metadata to be used by the next LFBs.
3164
3165
3166 [EthernetAll]
3167
3168
3169 [PHYPortID]
3170
3171
3172
3173
3174
3175
3176 AdminStatus
3177 Admin status of the port
3178 PortStatusValues
3179 2
3180
3181
3182 LocalMACAddresses
3183 Local Mac addresses
3184
3185 IEEEMAC
3186
3187
3188
3189 L2BridgingPathEnable
3190 Is the LFB doing L2 Bridging?
3191 boolean
3192 false
3193
3194
3195 PromiscuousMode
3196 Is the LFB in Promiscuous Mode?
3197 boolean
3198 false
3199
3200
3201 TxFlowControl
3202 Transmit flow control
3203 boolean
3204 false
3205
3206
3207 RxFlowControl
3208 Receive flow control
3209 boolean
3210 false
3211
3212
3213 MACInStats
3214 MACIn statistics
3215 MACInStatsType
3216
3217
3218
3219
3220 EtherClassifier
3221 This LFB abstracts the process to decapsulate
3222 Ethernet packets and classify the data packets into
3223 various network layer data packets according to information
3224 included in the Ethernet packets headers.
3225 1.0
3226
3227
3228 EtherPktsIn
3229 Input port for data packet.
3230
3231
3232 [EthernetAll]
3233
3234
3235 [PHYPortID]
3236 [
3237 LogicalPortID]
3238
3239
3240
3241
3242
3243
3244 ClassifyOut
3245 Output port for classification.
3246
3247
3248 [Arbitrary]
3249
3250
3251 [PHYPortID]
3252 [SrcMAC]
3253 [DstMAC]
3254 [EtherType]
3255 [VlanID]
3256 [VlanPriority]
3257
3258
3259
3260
3261
3262
3263 EtherDispatchTable
3264 Ether classify dispatch table
3265 EtherDispatchTableType
3266
3267
3268 VlanInputTable
3269 Vlan input table
3270 VlanInputTableType
3271
3272
3273 EtherClassifyStats
3274 Ether classify statistic table
3275 EtherClassifyStatsTableType
3276
3277
3278
3279
3280 EtherEncap
3281 This LFB abstracts the process to encapsulate IP
3282 packets to Ethernet packets according to the L2 information.
3283
3284 1.0
3285
3286
3287 EncapIn
3288 A Single Packet Input
3289
3290
3291 [IPv4]
3292 [IPv6]
3293
3294
3295 [MediaEncapInfoIndex]
3296 [
3297 VlanPriority]
3298
3299
3300
3301
3302
3303
3304 SuccessOut
3305 Output port for Packets which have found
3306 Ethernet L2 information and have been successfully
3307 encapsulated to an Ethernet packet.
3308
3309
3310 [IPv4]
3311 [IPv6]
3312
3313
3314 [L2PortID]
3315
3316
3317
3318
3319 ExceptionOut
3320 All packets that fail with the other
3321 operations in this LFB are output via this port.
3322
3323
3324
3325 [IPv4]
3326 [IPv6]
3327
3328
3329 [ExceptionID]
3330 [MediaEncapInfoIndex]
3331 [VlanPriority]
3332
3333
3334
3335
3336
3337
3338 EncapTable
3339 Ethernet Encapsulation table.
3340 EncapTableType
3341
3342
3343
3344
3345 EtherMACOut
3346 EtherMACOut LFB abstracts an Ethernet port at MAC
3347 data link layer. It specifically describes Ethernet packet
3348 output process. Ethernet output functions are closely related
3349 to Ethernet input functions, therefore some components
3350 defined in this LFB are actually alias of EtherMACIn LFB.
3351
3352 1.0
3353
3354
3355 EtherPktsIn
3356 The Input Port of the EtherMACIn. It expects
3357 any kind of Ethernet frame.
3358
3359
3360 [EthernetAll]
3361
3362
3363 [PHYPortID]
3364
3365
3366
3367
3368
3369
3370 EtherPktsOut
3371 The Normal Output Port of the EtherMACOut. It
3372 can produce any kind of Ethernet frame and along with
3373 the frame passes the ID of the Physical Port as
3374 metadata to be used by the next LFBs.
3375
3376
3377 [EthernetAll]
3378
3379
3380 [PHYPortID]
3381
3382
3383
3384
3385
3386
3387 AdminStatus
3388 Admin status of the port. It is the alias of
3389 "AdminStatus" component defined in EtherMACIn.
3390
3391 PortStatusValues
3393
3394
3395 MTU
3396 Maximum transmission unit.
3397 uint32
3398
3399
3400 TxFlowControl
3401 Transmit flow control. It is the alias of
3402 "TxFlowControl" component defined in EtherMACIn.
3403
3404 boolean
3405
3406
3407 RxFlowControl
3408 Receive flow control. It is the alias of
3409 "RxFlowControl" component defined in EtherMACIn.
3410
3411 boolean
3412
3413
3414 MACOutStats
3415 MACOut statistics
3416 MACOutStatsType
3417
3418
3419
3420
3421 IPv4Validator
3422 An LFB that performs IPv4 packets validation
3423 according to RFC1812. At the same time, ipv4 unicast and
3424 multicast are classified in this LFB.
3425 1.0
3426
3427
3428 ValidatePktsIn
3429 Input port for data packet.
3430
3431
3432 [Arbitrary]
3433
3434
3435
3436
3437
3438
3439 IPv4UnicastOut
3440 Output for IPv4 unicast packet.
3441
3442
3443 [IPv4Unicast]
3444
3445
3446
3447
3448 IPv4MulticastOut
3449 Output for IPv4 multicast packet.
3450
3451
3452 [IPv4Multicast]
3453
3454
3455
3456
3457 ExceptionOut
3458 Output for exception packet.
3459
3460
3461 [IPv4]
3462
3463
3464 [ExceptionID]
3465
3466
3467
3468
3469 FailOut
3470 Output for failed validation packet.
3471
3472
3473
3474 [IPv4]
3475
3476
3477 [ValidateErrorID]
3478
3479
3480
3481
3482
3483
3484 IPv4ValidatorStats
3485 IPv4 validator statistics information.
3486
3487 IPv4ValidatorStatsType
3488
3490
3491
3492
3493 IPv6Validator
3494 An LFB that performs IPv6 packets validation
3495 according to RFC2460. At the same time, ipv6 unicast and
3496 multicast are classified in this LFB.
3497 1.0
3498
3499
3500 ValidatePktsIn
3501 Input port for data packet.
3502
3503
3504 [Arbitrary]
3505
3506
3507
3508
3509
3510
3511 IPv6UnicastOut
3512 Output for IPv6 unicast packet.
3513
3514
3515 [IPv6Unicast]
3516
3517
3518
3519
3520 IPv6MulticastOut
3521 Output for IPv6 multicast packet.
3522
3523
3524 [IPv6Multicast]
3525
3526
3527
3528
3529 ExceptionOut
3530 Output for exception packet.
3531
3532
3533 [IPv6]
3534
3535
3536 [ExceptionID]
3537
3539
3540
3541
3542 FailOut
3543 Output for failed validation packet.
3544
3545
3546
3547 [IPv6]
3548
3549
3550 [ValidateErrorID]
3551
3552
3553
3554
3555
3556
3557 IPv6ValidatorStats
3558 IPv6 validator statistics information.
3559
3560 IPv6ValidatorStatsType
3561
3562
3563
3564
3565 IPv4UcastLPM
3566 An LFB that performs IPv4 Longest Prefix Match
3567 Lookup.It is defined to provide some facilities to support
3568 users to implement equal-cost multi-path routing(ECMP) or
3569 reverse path forwarding (RPF).
3570 1.0
3571
3572
3573 PktsIn
3574 A Single Packet Input
3575
3576
3577 [IPv4Unicast]
3578
3579
3580
3581
3582
3583
3584 NormalOut
3585 This output port is connected with
3586 IPv4NextHop LFB
3587
3588
3589 [IPv4Unicast]
3590
3591
3592 [HopSelector]
3593
3594
3595
3596
3597 ECMPOut
3598 This output port is connected with ECMP LFB,
3599 if there is ECMP LFB in the FE.
3600
3601
3602 [IPv4Unicast]
3603
3604
3605 [HopSelector]
3606
3607
3608
3609
3610 ExceptionOut
3611 The output for the packet if an exception
3612 occurs
3613
3614
3615 [IPv4Unicast]
3616
3617
3618 [ExceptionID]
3619
3620
3621
3622
3623
3624
3625 IPv4PrefixTable
3626 The IPv4 prefix table.
3627 IPv4PrefixTableType
3628
3629
3630 IPv4UcastLPMStats
3631 Statistics for IPv4 Unicast Longest Prefix
3632 Match
3633 IPv4UcastLPMStatsType
3634
3636
3637
3638
3639 IPv6UcastLPM
3640 An LFB that performs IPv6 Longest Prefix Match
3641 Lookup.It is defined to provide some facilities to support
3642 users to implement equal-cost multi-path routing(ECMP) or
3643 reverse path forwarding (RPF).
3644 1.0
3645
3646
3647 PktsIn
3648 A Single Packet Input
3649
3650
3651 [IPv6Unicast]
3652
3653
3654
3655
3656
3657
3658 NormalOut
3659 This output port is connected with
3660 IPv6NextHop LFB
3661
3662
3663 [IPv6Unicast]
3664
3665
3666 [HopSelector]
3667
3668
3669
3670
3671 ECMPOut
3672 This output port is connected with ECMP LFB,
3673 if there is ECMP LFB in the FE.
3674
3675
3676 [IPv6Unicast]
3677
3678
3679 [HopSelector]
3680
3681
3682
3683
3684 ExceptionOut
3685 The output for the packet if an exception
3686 occurs
3687
3688
3689 [IPv6Unicast]
3690
3691
3692 [ExceptionID]
3693
3694
3695
3696
3697
3698
3699 IPv6PrefixTable
3700 The IPv6 prefix table.
3701 IPv6PrefixTableType
3702
3703
3704 IPv6UcastLPMStats
3705 Statistics for IPv6 Unicast Longest Prefix
3706 Match
3707 IPv6UcastLPMStatsType
3708
3709
3710
3711
3712 IPv4NextHop
3713 This LFB abstracts the process of selecting ipv4
3714 next hop action. It receives an IPv4 packet with an
3715 associated next hop ID, and uses the ID to look up a next
3716 hop table to find an appropriate output port from the LFB.
3717
3718 1.0
3719
3720
3721 PktsIn
3722 A Single Packet Input
3723
3724
3725 [IPv4Unicast]
3726
3727
3728 [HopSelector]
3729
3730
3731
3733
3734
3735
3736 SuccessOut
3737 The output for the packet if it is valid to be
3738 forwarded
3739
3740
3741 [IPv4Unicast]
3742
3743
3744 [L3PortID]
3745 [NextHopIPv4Addr]
3746 [
3747 MediaEncapInfoIndex]
3748
3749
3750
3751
3752 ExceptionOut
3753 The output for the packet if an exception
3754 occurs
3755
3756
3757 [IPv4Unicast]
3758
3759
3760 [ExceptionID]
3761
3762
3763
3764
3765
3766
3767 IPv4NextHopTable
3768 The next hop table.
3769 IPv4NextHopTableType
3770
3771
3772
3773
3774 IPv6NextHop
3775 The LFB abstracts the process of next hop
3776 information application to IPv6 packets. It receives an IPv4
3777 packet with an associated next hop ID, and uses the ID to
3778 look up a next hop table to find an appropriate output port
3779 from the LFB..
3780 1.0
3781
3782
3783 PktsIn
3784 A single packet input.
3785
3786
3787 [IPv6Unicast]
3788
3789
3790 [HopSelector]
3791
3792
3793
3794
3795
3796
3797 SuccessOut
3798 The output for the packet if it is valid to
3799 be forwarded
3800
3801
3802 [IPv6Unicast]
3803
3804
3805 [L3PortID]
3806 [NextHopIPv6Addr]
3807 [
3808 MediaEncapInfoIndex]
3809
3810
3811
3812
3813 ExceptionOut
3814 The output for the packet if an exception
3815 occurs
3816
3817
3818 [IPv6Unicast]
3819
3820
3821 [ExceptionID]
3822
3823
3824
3825
3826
3827
3828 IPv6NextHopTable
3829 The next hop table.
3830 IPv6NextHopTableType
3831
3832
3833
3834
3835 RedirectIn
3836 The RedirectIn LFB abstracts the process for CE to
3837 inject data packets into FE LFB topology, so as to input data
3838 packets into FE data paths. CE may associate some
3839 metadata to data packets to indicate various information on
3840 the packets. Among them, there MUST exist a 'RedirectIndex'
3841 metadata, which is an integer acting as an output port index.
3842
3843 1.0
3844
3845
3846 PktsOut
3847 This output group sends the redirected packet
3848 in the data path.
3849
3850
3851 [Arbitrary]
3852
3853
3854
3855
3856
3857
3858 RedirectOut
3859 The LFB abstracts the process for LFBs in
3860 FE to deliver data packets to CE. All metadata
3861 associated with the input packets will be delivered to CE
3862 via the redirect message of ForCES protocol [RFC5810].
3863
3864 1.0
3865
3866
3867 PktsIn
3868 This input receives packets to send to
3869 the CE.
3870
3871
3872 [Arbitrary]
3873
3874
3875
3876
3878
3879
3880 BasicMetadataDispatch
3881 This LFB provides the function to dispatch input
3882 packets to a group output according to a metadata and a
3883 dispatch table.This LFB currently only allow a metadata with
3884 an interger value to be used for dispatch.
3885 1.0
3886
3887
3888 PktsIn
3889 Input port for data packet.
3890
3891
3892 [Arbitrary]
3893
3894
3895 [Arbitrary]
3896
3897
3898
3899
3900
3901
3902 PktsOut
3903 Data packet output
3904
3905
3906 [Arbitrary]
3907
3908
3909
3910
3911
3912
3913 MetadataID
3914 the metadata ID for dispatching
3915 uint32
3916
3917
3918 MetadataDispatchTable
3919 Metadata dispatch table.
3920 MetadataDispatchTableType
3921
3922
3923
3924
3925 GenericScheduler
3926 This is a preliminary generic scheduler LFB for
3927 abstracting a simple scheduling process.Users may use this
3928 LFB as a basic scheduler LFB to further construct more
3929 complex scheduler LFBs by means of inheritance as described
3930 in RFC5812.
3931 1.0
3932
3933
3934 PktsIn
3935 Input port for data packet.
3936
3937
3938 [Arbitrary]
3939
3940
3941
3942
3943
3944
3945 PktsOut
3946 Data packet output.
3947
3948
3949 [Arbitrary]
3950
3951
3952
3953
3954
3955
3956 QueueCount
3957 The number of queues to be scheduled.
3958
3959 uint32
3960
3961
3962 SchedulingDiscipline
3963 the Scheduler discipline.
3964 SchdDisciplineType
3965
3966
3967 QueueStats
3968 Current statistics for all queues
3969 QueueStatsTableType
3970
3971
3972
3973
3974 QueueLenLimit
3975 Maximum length of each queue,the unit is
3976 byte.
3977 uint32
3978
3979
3980
3981
3982
3983 7. LFB Class Use Cases
3985 This section demonstrates examples on how the LFB classes defined by
3986 the Base LFB library in Section 6 can be applied to achieve some
3987 typical router functions. The functions demonstrated are:
3989 o IPv4 forwarding
3991 o ARP processing
3993 It is assumed the LFB topology on the FE described has already been
3994 established by the CE and maps to the use cases illustrated in this
3995 section.
3997 The use cases demonstrated in this section are mere examples and by
3998 no means should be treated as the only way one would construct router
3999 functionality from LFBs; based on the capability of the FE(s), a CE
4000 should be able to express different NE applications.
4002 7.1. IPv4 Forwarding
4004 Figure 1 (Section 3.2.3) shows a typical IPv4 forwarding processing
4005 path by use of the base LFB classes.
4007 A number of EtherPHYCop LFB(Section 5.1.1) instances are used to
4008 describe physical layer functions of the ports. PHYPortID metadata
4009 is generated by EtherPHYCop LFB and is used by all the subsequent
4010 downstream LFBs. An EtherMACIn LFB(Section 5.1.2), which describe
4011 the MAC layer processing, follows every EtherPHYCop LFB. The
4012 EtherMACIn LFB may do a locality check of MAC addresses if the CE
4013 configures the appropriate EtherMACIn LFB component.
4015 Ethernet packets out of the EtherMACIn LFB are sent to an
4016 EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified
4017 into network layer types like IPv4, IPv6, ARP, etc. In the example
4018 use case, every physical Ethernet interface is associated with one
4019 Classifier instance; although not illustrated, it is also feasible
4020 that all physical interfaces are associated with only one Ethernet
4021 Classifier instance.
4023 EtherClassifier uses the PHYPortID metadata, the Ethernet type of the
4024 input packet, and VlanID (if present in the input Ethernet packets),
4025 to decide the packet network layer type and the LFB output port to
4026 the downstream LFB. The EtherClassifier LFB also assigns a new
4027 logical port ID metadata to the packet for later use. The
4028 EtherClassifier may also generate some new metadata for every packet
4029 like EtherType, SrcMAC, DstMAC, LogicPortID, etc for consumption by
4030 downstream LFBs.
4032 If a packet is classified as an IPv4 packet, it is sent downstream to
4033 an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet. In
4034 the validator LFB, IPv4 packets are validated and are additionally
4035 classified into either IPv4 unicast packets or multicast packets.
4036 IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB
4037 (Section 5.3.1).
4039 The IPv4UcastLPM LFB is where the longest prefix match decision is
4040 made, and a next hop selection is selected. The nexthop ID metadata
4041 is generated by the IPv4UcastLPM LFB to be consumed downstream by the
4042 IPv4NextHop LFB (Section 5.3.2).
4044 The IPv4NextHop LFB uses the nexthop ID metadata to do derive where
4045 the packet is to go next and the media encapsulation type for the
4046 port, etc. The IPv4NextHop LFB generates the L3PortID metadata used
4047 to identify a next hop output physical/logical port. In the example
4048 use case, the next hop output port is an Ethernet type; as a result,
4049 the packet and its L3 port ID metadata are sent downstream to an
4050 EtherEncap LFB (Section 5.1.4).
4052 The EtherEncap LFB encapsulates the incoming packet into an Ethernet
4053 frame. A BasicMetadataDispatch LFB (Section 5.5.1) follows the
4054 EtherEncap LFB. The BasicMetadataDispatch LFB is where packets are
4055 finally dispatched to different output physical/logical ports based
4056 on the L3PortID metadata sent to the LFB.
4058 7.2. ARP processing
4060 Figure 2 shows the processing path for ARP protocol in the case the
4061 CE implements the ARP processing function. By no means is this the
4062 only way ARP processing could be achieved; as an example ARP
4063 processing could happen at the FE - but that discussion is out of
4064 scope for this use case.
4066 +---+ +---+
4067 | | ARP packets | |
4068 | |------------------------+--->| | To CE
4069 ...-->| | . | | |
4070 | | . | +---+
4071 | | . | RedirectOut
4072 +---+ |
4073 Ether EtherEncap | IPv4 packets lack
4074 Classifier +---+ | address resolution information
4075 | | |
4076 Packets need | |--------->---+
4077 ...--------->| |
4078 L2 Encapsulation| |
4079 +---+ | | +------+
4080 | | +-->| |--+ +---+ |Ether |
4081 | | | +---+ | | |--------->|MACOut|-->...
4082 From CE| |--+ +-->| | . +------+
4083 | |ARP Packets | | .
4084 | |from CE | | . +------+
4085 | | | |--------> |Ether |-->...
4086 +---+ +---+ |MACOut|
4087 RedirectIn BasicMetadata +------+
4088 Dispatch
4090 Figure 2: LFB use case for ARP
4092 There are two ways ARP processing could be triggered in the CE as
4093 illustrated in Figure 2:
4095 o ARP packets arriving from outside of the NE.
4097 o IPV4 packets failing to resolve within the FE.
4099 ARP packets from network interfaces are filtered out by
4100 EtherClassifier LFB. The classified ARP packets and associated
4101 metadata are then sent downstream to the RedirectOut LFB
4102 (Section 5.4.2) to be transported to CE.
4104 The EtherEncap LFB, as described earlier, receives packets that need
4105 Ethernet L2 encapsulating. When the EtherEncap LFB fails to find the
4106 necessary L2 Ethernet information to encapsulate the packet with, it
4107 outputs the packet to its ExceptionOut LFB port. Downstream to
4108 EtherEncap LFB's ExceptionOut LFB port is the RedirectOut LFB which
4109 transports the packet to the CE (Section 5.1.4 on EtherEncap LFB for
4110 details).
4112 To achieve its goal, the CE needs to generate ARP request and
4113 response packets and send them to external (to the NE) networks. ARP
4114 request and response packets from the CE are redirected to an FE via
4115 a RedirectIn LFB (Section 5.4.1).
4117 As was the case with forwarded IPv4 packets, outgoing ARP packets are
4118 also encapsulated to Ethernet format by the EtherEncap LFB, and then
4119 dispatched to different interfaces via a BasicMetadataDispatch LFB.
4120 The BasicMetadataDispatch LFB dispatches the packets according to the
4121 L3PortID metadata included in every ARP packet sent from CE.
4123 8. Contributors
4125 The authors would like to thank Jamal Hadi Salim, Ligang Dong, and
4126 Fenggen Jia who made major contributions to the development of this
4127 document.
4129 Jamal Hadi Salim
4130 Mojatatu Networks
4131 Ottawa, Ontario
4132 Canada
4133 Email: hadi@mojatatu.com
4135 Ligang Dong
4136 Zhejiang Gongshang University
4137 149 Jiaogong Road
4138 Hangzhou 310035
4139 P.R.China
4140 Phone: +86-571-28877751
4141 EMail: donglg@mail.zjgsu.edu.cn
4143 Fenggen Jia
4144 National Digital Switching Center(NDSC)
4145 Jianxue Road
4146 Zhengzhou 452000
4147 P.R.China
4148 EMail: jfg@mail.ndsc.com.cn
4150 9. Acknowledgements
4152 This document is based on earlier documents from Joel Halpern, Ligang
4153 Dong, Fenggen Jia and Weiming Wang.
4155 10. IANA Considerations
4157 IANA has created a registry of ForCES LFB Class Names and the
4158 corresponding ForCES LFB Class Identifiers, with the location of the
4159 definition of the ForCES LFB Class, in accordance with the rules to
4160 use the namespace.
4162 The LFB library in this document needs for unique class names and
4163 numeric class identifiers of all LFBs. Besides, this document also
4164 needs to define the following namespaces:
4166 o Metadata ID, defined in Section 4.3 and Section 4.4
4168 o Exception ID, defined in Section 4.4
4170 o Validate Error ID, defined in Section 4.4
4172 10.1. LFB Class Names and LFB Class Identifiers
4174 LFB classes defined by this document belongs to IETF defined LFBs by
4175 Standard Track RFCs. According to IANA, the identifier namespace for
4176 these LFB classes is from 3 to 65535.
4178 The assignment of LFB class names and LFB class identifiers is as in
4179 the following table.
4181 +-----------+---------------+------------------------+--------------+
4182 | LFB Class | LFB Class Name| Description | Reference |
4183 | Identifier| | | |
4184 +-----------+---------------+------------------------+--------------+
4185 | 3 | EtherPHYCop | Define an Ethernet port| RFC????(this|
4186 | | | abstracted at physical | document) |
4187 | | | layer | Section 5.1.1|
4188 | | | -------------- | |
4189 | 4 | EtherMACIn | Define an Ethernet | RFC???? |
4190 | | | input port at MAC data | Section 5.1.2|
4191 | | | link layer | |
4192 | | | -------------- | |
4193 | 5 |EtherClassifier| Define the process to | RFC???? |
4194 | | | decapsulate Ethernet | Section 5.1.3|
4195 | | | packets and classify | |
4196 | | | the packets | |
4197 | | | -------------- | |
4198 | 6 | EtherEncap | Define the process to | RFC???? |
4199 | | | encapsulate IP packets | Section 5.1.4|
4200 | | | to Ethernet packets | |
4201 | | | -------------- | |
4202 | 7 | EtherMACOut | Define an Ethernet | RFC ???? |
4203 | | | output port at MAC | Section 5.1.5|
4204 | | | data link layer | |
4205 | | | -------------- | |
4206 | 8 | IPv4Validator | Perform IPv4 packets | RFC ???? |
4207 | | | validation. | Section 5.2.1|
4208 | | | -------------- | |
4209 | 9 | IPv6Validator | Perform IPv6 packets | RFC ???? |
4210 | | | validation | Section 5.2.2|
4211 | | | -------------- | |
4212 | 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? |
4213 | | | Prefix Match Lookup | Section 5.3.1|
4214 | | | -------------- | |
4215 | 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? |
4216 | | | Prefix Match Lookup | Section 5.3.3|
4217 | | | -------------- | |
4218 | 12 | IPv4NextHop | Define the process of | RFC ??? |
4219 | | | selecting Ipv4 next hop| Section 5.3.2|
4220 | | | action | |
4221 | | | -------------- | |
4222 | 13 | IPv6NextHop | Define the process of | RFC ??? |
4223 | | | selecting Ipv6 next hop| Section 5.3.4|
4224 | | | action | |
4225 | | | -------------- | |
4226 | 14 | RedirectIn | Define the process for | RFC ??? |
4227 | | | CE to inject data | Section 5.4.1|
4228 | | | packets into FE LFB | |
4229 | | | topology | |
4230 | | | -------------- | |
4231 | 15 | RedirectOut | Define the process for | RFC ??? |
4232 | | | LFBs in FE to deliver | Section 5.4.2|
4233 | | | data packets to CE | |
4234 | | | -------------- | |
4235 | 16 |BasicMetadata | Dispatch input packets | RFC ??? |
4236 | |Dispatch | to a group output | Section 5.5.1|
4237 | | | according to a metadata| |
4238 | | | -------------- | |
4239 | 17 |Generic | Define a preliminary | RFC ???? |
4240 | |Scheduler | generic scheduling | Section 5.5.2|
4241 | | | process | |
4242 +-----------+---------------+------------------------+--------------+
4244 Table 1
4246 10.2. Metadata ID
4248 The Metadata ID namespace is 32 bits long. The following is the
4249 guideline for managing the namespace.
4251 Metadata ID 0x00000000-0x7FFFFFFF
4252 Metadata with IDs in this range are Specification Required
4253 [RFC5226]. A metadata ID using this range MUST be documented in
4254 an RFC or other permanent and readily available references.
4256 Values assigned by this specification:
4258 +--------------+-------------------------+--------------------------+
4259 | Value | Name | Definition |
4260 +--------------+-------------------------+--------------------------+
4261 | 0x00000001 | PHYPortID | See Section 4.4 |
4262 | 0x00000002 | SrcMAC | See Section 4.4 |
4263 | 0x00000003 | DstMAC | See Section 4.4 |
4264 | 0x00000004 | LogicalPortID | See Section 4.4 |
4265 | 0x00000005 | EtherType | See Section 4.4 |
4266 | 0x00000006 | VlanID | See Section 4.4 |
4267 | 0x00000007 | VlanPriority | See Section 4.4 |
4268 | 0x00000008 | NexthopIPv4Addr | See Section 4.4 |
4269 | 0x00000009 | NexthopIPv6Addr | See Section 4.4 |
4270 | 0x0000000A | HopSelector | See Section 4.4 |
4271 | 0x0000000B | ExceptionID | See Section 4.4 |
4272 | 0x0000000C | ValidateErrorID | See Section 4.4 |
4273 | 0x0000000D | L3PortID | See Section 4.4 |
4274 | 0x0000000E | RedirectIndex | See Section 4.4 |
4275 | 0x0000000F | MediaEncapInfoIndex | See Section 4.4 |
4276 +--------------+-------------------------+--------------------------+
4278 Table 2
4280 Metadata ID 0x80000000-0xFFFFFFFF
4281 Metadata IDs in this range are reserved for vendor private
4282 extensions and are the responsibility of individuals.
4284 10.3. Exception ID
4286 The Exception ID namespace is 32 bits long. The following is the
4287 guideline for managing the namespace.
4289 Exception ID 0x00000000-0x7FFFFFFF
4290 Exception IDs in this range are Specification Required [RFC5226].
4291 An exception ID using this range MUST be documented in an RFC or
4292 other permanent and readily available references.
4294 Values assigned by this specification:
4296 +--------------+---------------------------------+------------------+
4297 | Value | Name | Definition |
4298 +--------------+---------------------------------+------------------+
4299 | 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 |
4300 | 0x00000001 | ClassifyNoMatching | See Section 4.4 |
4301 | 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 |
4302 | 0x00000003 | EncapTableLookupFailed | See Section 4.4 |
4303 | 0x00000004 | BadTTL | See Section 4.4 |
4304 | 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 |
4305 | 0x00000006 | RouterAlertOptions | See Section 4.4 |
4306 | 0x00000007 | IPv6HopLimitZero | See Section 4.4 |
4307 | 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 |
4308 | 0x00000009 | SrcAddressExecption | See Section 4.4 |
4309 | 0x0000000A | DstAddressExecption | See Section 4.4 |
4310 | 0x0000000B | LPMLookupFailed | See Section 4.4 |
4311 | 0x0000000C | HopSelectorInvalid | See Section 4.4 |
4312 | 0x0000000D | NextHopLookupFailed | See Section 4.4 |
4313 | 0x0000000E | FragRequired | See Section 4.4 |
4314 | 0x0000000F | MetadataNoMatching | See Section 4.4 |
4315 +--------------+---------------------------------+------------------+
4317 Table 3
4319 Exception ID 0x80000000-0xFFFFFFFF
4320 Exception IDs in this range are reserved for vendor private
4321 extensions and are the responsibility of individuals.
4323 10.4. Validate Error ID
4325 The Validate Error ID namespace is 32 bits long. The following is
4326 the guideline for managing the namespace.
4328 Validate Error ID 0x00000000-0x7FFFFFFF
4329 Validate Error IDs in this range are Specification Required
4330 [RFC5226]. A Validate Error ID using this range MUST be
4331 documented in an RFC or other permanent and readily available
4332 references.
4334 Values assigned by this specification:
4336 +--------------+---------------------------------+------------------+
4337 | Value | Name | Definition |
4338 +--------------+---------------------------------+------------------+
4339 | 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 |
4340 | 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 |
4341 | 0x00000002 | NotIPv4Packet | See Section 4.4 |
4342 | 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 |
4343 | 0x00000004 | InvalidIPv4LengthFieldSize | See Section 4.4 |
4344 | 0x00000005 | InvalidIPv4Checksum | See Section 4.4 |
4345 | 0x00000006 | InvalidIPv4SrcAddr | See Section 4.4 |
4346 | 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 |
4347 | 0x00000008 | InvalidIPv6PakcetSize | See Section 4.4 |
4348 | 0x00000009 | NotIPv6Packet | See Section 4.4 |
4349 | 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 |
4350 | 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 |
4351 +--------------+---------------------------------+------------------+
4352 Table 4
4354 Validate Error ID 0x80000000-0xFFFFFFFF
4355 Validate Error IDs in this range are reserved for vendor private
4356 extensions and are the responsibility of individuals.
4358 11. Security Considerations
4360 The ForCES framework document [RFC3746] provides a comprehensive
4361 security analysis for the overall ForCES architecture. For example,
4362 the ForCES protocol entities must be authenticated per the ForCES
4363 requirements before they can access the information elements
4364 described in this document via ForCES. Access to the information
4365 contained in this document is accomplished via the ForCES
4366 protocol[RFC5810], which is defined in separate documents, and thus
4367 the security issues will be addressed there.
4369 12. References
4371 12.1. Normative References
4373 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
4374 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
4375 Control Element Separation (ForCES) Protocol
4376 Specification", RFC 5810, March 2010.
4378 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
4379 Element Separation (ForCES) Forwarding Element Model",
4380 RFC 5812, March 2010.
4382 12.2. Informative References
4384 [RFC1122] Braden, R., "Requirements for Internet Hosts -
4385 Communication Layers", STD 3, RFC 1122, October 1989.
4387 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
4388 RFC 1812, June 1995.
4390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
4391 Requirement Levels", BCP 14, RFC 2119, March 1997.
4393 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
4394 (IPv6) Specification", RFC 2460, December 1998.
4396 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
4397 June 1999.
4399 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
4400 Text on Security Considerations", BCP 72, RFC 3552,
4401 July 2003.
4403 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
4404 of IP Control and Forwarding", RFC 3654, November 2003.
4406 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
4407 "Forwarding and Control Element Separation (ForCES)
4408 Framework", RFC 3746, April 2004.
4410 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
4411 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
4412 May 2008.
4414 Authors' Addresses
4416 Weiming Wang
4417 Zhejiang Gongshang University
4418 18 Xuezheng Str., Xiasha University Town
4419 Hangzhou, 310018
4420 P.R.China
4422 Phone: +86 571 28877721
4423 Email: wmwang@zjsu.edu.cn
4425 Evangelos Haleplidis
4426 University of Patras
4427 Patras,
4428 Greece
4430 Email: ehalep@ece.upatras.gr
4432 Kentaro Ogawa
4433 NTT Corporation
4434 Tokyo,
4435 Japan
4437 Email: ogawa.kentaro@lab.ntt.co.jp
4439 Chuanhuang Li
4440 Hangzhou H3C Tech. Co., Ltd.
4441 310 Liuhe Road, Zhijiang Science Park
4442 Hangzhou, 310053
4443 P.R.China
4445 Phone: +86 571 86760000
4446 Email: chuanhuang_li@zjsu.edu.cn
4448 Halpern Joel
4449 Ericsson
4450 P.O. Box 6049
4451 Leesburg, 20178
4452 VA
4454 Phone: +1 703 371 3043
4455 Email: joel.halpern@ericsson.com