idnits 2.17.1
draft-ietf-forces-lfb-lib-12.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 (March 29, 2013) is 4043 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 512, but not defined
== Unused Reference: 'RFC2629' is defined on line 5053, but no explicit
reference was found in the text
== Unused Reference: 'RFC3552' is defined on line 5056, but no explicit
reference was found in the text
== Unused Reference: 'RFC3654' is defined on line 5060, 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 (~~), 5 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: September 30, 2013 University of Patras
6 K. Ogawa
7 NTT Corporation
8 C. Li
9 Hangzhou DPtech
10 J. Halpern
11 Ericsson
12 March 29, 2013
14 ForCES Logical Function Block (LFB) Library
15 draft-ietf-forces-lfb-lib-12
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 September 30, 2013.
44 Copyright Notice
46 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . 11
69 3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12
70 3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13
71 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 14
72 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 14
73 4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 14
74 4.1.2. Compound Struct . . . . . . . . . . . . . . . . . . . 15
75 4.1.3. Compound Array . . . . . . . . . . . . . . . . . . . 15
76 4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 16
77 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 16
78 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 17
79 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 43
80 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43
81 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44
82 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46
83 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 48
84 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50
85 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52
86 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53
87 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 54
88 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55
89 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 57
90 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 57
91 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59
92 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61
93 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63
94 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65
95 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65
96 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66
97 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67
98 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 67
99 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 69
100 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 71
101 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 100
102 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 100
103 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 102
104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 105
105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106
106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
107 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 107
108 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 109
109 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 109
110 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 110
111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 112
112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
113 12.1. Normative References . . . . . . . . . . . . . . . . . . 113
114 12.2. Informative References . . . . . . . . . . . . . . . . . 113
115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115
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.
208 Physical Port - A port refers to a physical media input port or
209 output port of an FE. A physical port is usually assigned with a
210 physical port ID, abbreviated with a PHYPortID. This document
211 mainly deals with physical ports with Ethernet media.
213 Logical Port - A conceptually virtual port at data link layer (L2)
214 or network layer (L3). A logical port is usually assigned with a
215 logical port ID, abbreviated with a LogicalPortID. The logical
216 ports can be further categorized with a L2 logical port or a L3
217 logical port. An L2 logical port can be assigned with a L2
218 logical port ID, abbreviated with a L2PortID. An L3 logical port
219 can be assigned with a L3 logical port ID, abbreviated with a
220 L3PortID. MAC layer VLAN ports belongs to L2 logical ports as
221 well as logical ports.
223 LFB Port - The connection points where one LFB can be connected to
224 another within an FE. As described in [RFC5812], the CE can
225 connect LFBs together by establishing connections between an
226 output port of one LFB instance and an input port of another LFB
227 instance. Also see Section 3.2 of [RFC5812] for more details.
229 Singleton Port - A named input or output port of an LFB. This
230 port is referred to by a name. When the context is clear, the
231 term singleton by itself is used to refer to a singleton port.
233 Group Port - A named collection of input or output ports of an
234 LFB. A group port is referred to by a name. Whereas, a group
235 port consists of a number of port instances, which are referred to
236 by a combination of a name and an index.
238 LFB Class Library - The LFB class library is a set of LFB classes
239 that has been identified as the most common functions found in
240 most FEs and hence should be defined first by the ForCES Working
241 Group. The LFB Class Library is defined by this document.
243 3. Introduction
245 [RFC3746] specifies Forwarding and Control Element Separation
246 (ForCES) framework. In the framework, Control Elements (CEs)
247 configure and manage one or more separate Forwarding Elements (FEs)
248 within a Network Element (NE) by use of a ForCES protocol. [RFC5810]
249 specifies the ForCES protocol. [RFC5812] specifies the Forwarding
250 Element (FE) model. In the model, resources in FEs are described by
251 classes of Logical Function Blocks (LFBs). The FE model defines the
252 structure and abstract semantics of LFBs, and provides XML schema for
253 the definitions of LFBs.
255 This document conforms to the specifications of the FE model
256 [RFC5812] and specifies detailed definitions of classes of LFBs,
257 including detailed XML definitions of LFBs. These LFBs form a base
258 LFB library for ForCES. LFBs in the base library are expected to be
259 combined to form an LFB topology for a typical router to implement IP
260 forwarding. It should be emphasized that an LFB is an abstraction of
261 functions rather than its implementation details. The purpose of the
262 LFB definitions is to represent functions so as to provide
263 interoperability between separate CEs and FEs.
265 More LFB classes with more functions may be developed in future time
266 and documented by IETF. Vendors may also develop proprietary LFB
267 classes as described in the FE model [RFC5812].
269 3.1. Scope of the Library
271 It is intended that the LFB classes described in this document are
272 designed to provide the functions of a typical router. [RFC1812]
273 specifies that a typical router is expected to provide functions to:
275 (1) Interface to packet networks and implement the functions
276 required by that network. These functions typically include:
278 * Encapsulating and decapsulating the IP datagrams with the
279 connected network framing (e.g., an Ethernet header and
280 checksum),
282 * Sending and receiving IP datagrams up to the maximum size
283 supported by that network, this size is the network's Maximum
284 Transmission Unit or MTU,
286 * Translating the IP destination address into an appropriate
287 network-level address for the connected network (e.g., an
288 Ethernet hardware address), if needed, and
290 * Responding to network flow control and error indications, if
291 any.
293 (2) Conform to specific Internet protocols including the Internet
294 Protocol (IPv4 and/or IPv6), Internet Control Message Protocol
295 (ICMP), and others as necessary.
297 (3) Receive and forward Internet datagrams. Important issues in
298 this process are buffer management, congestion control, and
299 fairness.
301 * Recognizes error conditions and generates ICMP error and
302 information messages as required.
304 * Drops datagrams whose time-to-live fields have reached zero.
306 * Fragments datagrams when necessary to fit into the MTU of the
307 next link or interface.
309 (4) Choose a next hop destination for each IP datagram, based on the
310 information in its routing database.
312 (5) Usually support an interior gateway protocol (IGP) to carry out
313 distributed routing and reachability algorithms with the other
314 routers in the same autonomous system. In addition, some
315 routers will need to support an exterior gateway protocol (EGP)
316 to exchange topological information with other autonomous
317 systems. For all routers, it is essential to provide ability to
318 manage static routing items.
320 (6) Provide network management and system support facilities,
321 including loading, debugging, status reporting, statistcs query,
322 exception reporting and control.
324 The classical IP router utilizing the ForCES framework constitutes a
325 CE running some controlling IGP and/or EGP function or static route
326 setup and FEs implementing using Logical Function Blocks (LFBs)
327 conforming to the FE model[RFC5812] specifications. The CE, in
328 conformance to the ForCES protocol[RFC5810] and the FE model
329 [RFC5812] specifications, instructs the LFBs on the FE how to treat
330 received/sent packets.
332 Packets in an IP router are received and transmitted on physical
333 media typically referred to as "ports". Different physical port
334 media will have different ways for encapsulating outgoing frames and
335 decapsulating incoming frames. The different physical media will
336 also have different attributes that influence its behavior and how
337 frames get encapsulated or decapsulated. This document will only
338 deal with Ethernet physical media. Other future documents may deal
339 with other type of media. This document will also interchangeably
340 refer to a port to be an abstraction that constitutes a PHY and a MAC
341 as described by the LFBs like EtherPHYCop, EtherMACIn, and
342 EtherMACOut.
344 IP packets emanating from port LFBs are then processed by a
345 validation LFB before being further forwarded to the next LFB. After
346 the validation process the packet is passed to an LFB where IP
347 forwarding decision is made. In the IP Forwarding LFBs, a Longest
348 Prefix Match LFB is used to look up the destination information in a
349 packet and select a next hop index for sending the packet onward. A
350 next hop LFB uses the next hop index metadata to apply the proper
351 headers to the IP packets, and direct them to the proper egress.
352 Note that in the process of IP packets processing, in this document,
353 we are adhering to the weak-host model [RFC1122] since that is the
354 most usable model for a packet processing Network Element.
356 3.2. Overview of LFB Classes in the Library
358 It is critical to classify functional requirements into various
359 classes of LFBs and construct a typical but also flexible enough base
360 LFB library for various IP forwarding equipments.
362 3.2.1. LFB Design Choices
364 A few design principles were factored into choosing how the base LFBs
365 looked like. These are:
367 o If a function can be designed by either one LFB or two or more
368 LFBs with the same cost, the choice is to go with two or more LFBs
369 so as to provide more flexibility for implementers.
371 o An LFB should take advantage of its independence as much as
372 possible and have minimal coupling with other LFBs. The coupling
373 may be from LFB attributes definitions as well as physical
374 implementations.
376 o Unless there is a clear difference in functionality, similar
377 packet processing in the base LFB library should not be
378 represented simultaneously as two or more LFBs. For instance, it
379 should not be simultaneously defined with two different LFBs for
380 the same next hop processing. Or else, it may add extra burden on
381 implementation to achieve interoperability.
383 3.2.2. LFB Class Groupings
385 The document defines groups of LFBs for typical router function
386 requirements:
388 (1) A group of Ethernet processing LFBs are defined to abstract the
389 packet processing for Ethernet as the port media type. As the
390 most popular media type with rich processing features, Ethernet
391 media processing LFBs was a natural choice. Definitions for
392 processing of other port media type like POS or ATM may be
393 incorporated in the library in future version of the document or
394 in a future separate document. The following LFBs are defined
395 for Ethernet processing:
397 * EtherPHYCop (Section 5.1.1)
399 * EtherMACIn (Section 5.1.2)
401 * EtherClassifier (Section 5.1.3)
403 * EtherEncap (Section 5.1.4)
405 * EtherMACOut (Section 5.1.5)
407 (2) A group of LFBs are defined for IP packet validation process.
408 The following LFBs are defined for IP validation processing:
410 * IPv4Validator (Section 5.2.1)
412 * IPv6Validator (Section 5.2.2)
414 (3) A group of LFBs are defined to abstract IP forwarding process.
415 The following LFBs are defined for IP forwarding processing:
417 * IPv4UcastLPM (Section 5.3.1)
419 * IPv4NextHop (Section 5.3.2)
421 * IPv6UcastLPM (Section 5.3.3)
423 * IPv6NextHop (Section 5.3.4)
425 (4) A group of LFBs are defined to abstract the process for redirect
426 operation, i.e., data packet transmission between CE and FEs.
427 The following LFBs are defined for redirect processing:
429 * RedirectIn (Section 5.4.1)
430 * RedirectOut (Section 5.4.2)
432 (5) A group of LFBs are defined for abstracting some general purpose
433 packet processing. These processing processes are usually
434 general to many processing locations in an FE LFB topology. The
435 following LFBs are defined for redirect processing:
437 * BasicMetadataDispatch (Section 5.5.1)
439 * GenericScheduler (Section 5.5.2)
441 3.2.3. Sample LFB Class Application
443 Although Section 7 will present use cases for LFBs defined in this
444 document, this section shows a simple sample LFB class application in
445 advance so that readers can get a quick overlook of the LFB classes
446 with the usage.
448 Figure 1 shows a simple LFB processing path for Ethernet packets
449 entered from Ethernet physical ports.
451 +-----+ +------+
452 | |EtherPHYIn | | from some LFB(s) which
453 | |<---------------|Ether |<---------- generate Ethernet
454 | | |MACOut| packets
455 | | | LFB |
456 |Ether| +------+
457 |PHY | +------+
458 |Cop | | |
459 |LFB |EtherPHYOut | Ether| to some LFB(s) which
460 | |--------------->| MACIn|----------> may classify Ethernet
461 | | | LFB | packets and do IP layer
462 | | | | processing
463 +-----+ +------+
465 Figure 1: A simple sample LFB use case
467 In the figure, Ethernet packets from outer networks enter via the
468 EtherPHYCop LFB(Section 5.1.1), which describes Ethernet copper
469 interface property(like the link speed) at physical layer. After
470 physical layer process, Ethernet packets are delivered to EtherMACIn
471 LFB(Section 5.1.2) to describe its MAC layer processing
472 functions(like locality check). The packets after EtherMACIn LFB may
473 require further processing to implement various functions(like IP
474 layer forwarding),therefore some LFBs may follow the EtherMACIn LFB
475 in topology to describe followed processing functions.
477 Meanwhile, packets generated by some LFB(s) may need to be submitted
478 to outer physical networks. The process is described in the figure
479 by an EtherMACOut LFB(Section 5.1.5) at MAC layer and the EtherPHYCop
480 LFB at physical layer.
482 3.3. Document Structure
484 Base type definitions, including data types, packet frame types, and
485 metadata types are presented in advance for definitions of various
486 LFB classes. Section 4 (Base Types section) provides a description
487 on the base types used by this LFB library. To enable extensive use
488 of these base types by other LFB class definitions, the base type
489 definitions are provided as a separate library.
491 Within every group of LFB classes, a set of LFBs are defined for
492 individual function purposes. Section 5 (LFB Class Descriptions
493 section) provides text descriptions on the individual LFBs. Note
494 that for a complete definition of an LFB, a text description as well
495 as a XML definition is required.
497 LFB classes are finally defined by XML with specifications and schema
498 defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB
499 Definitions section) provides the complete XML definitions of the
500 base LFB classes library.
502 Section 7 provides several use cases on how some typical router
503 functions can be implemented using the base LFB library defined in
504 this document.
506 4. Base Types
508 The FE model [RFC5812] has specified predefined (built-in) atomic
509 data-types as below:
511 char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
512 string, byte[N], boolean, octetstring[N], float16, float32, float64.
514 Note that, unlike SNMP information model SMI([RFC2578]), the FE model
515 has not defined specific atomic data type for counting purpose. This
516 document follows not to define specific counter types. To describe
517 LFB elements for packet statistics which actually require counters on
518 packets, an unsigned integer, like an uint32 or an uint64 is adopted.
519 This document states that any LFB element defined for counter purpose
520 is specified to monotonically increase until it reaches a maximum
521 value, when it wraps around and starts increasing again from zero.
522 This document also states that it is implementation's issue how the
523 unsigned integer element might be maintained to cope with issues like
524 counter discontinuities when a counter wraps or is reset by any
525 reasons. If a CE is expected to understand more meanings of the
526 counter element than stated above, a private definition on the
527 element between CE and FE may be required.
529 Based on the atomic data types and with the use of type definition
530 elements in the FE model XML schema, new data types, packet frame
531 types, and metadata types can be defined.
533 To define a base LFB library for typical router functions, a set of
534 base data types, frame types, and metadata types should be defined.
535 This section provides a brief description of the base types and a
536 full XML definition of them as well.
538 The base type XML definitions are provided with a separate XML
539 library file named "BaseTypeLibrary". Users can refer to this
540 library by the statement:
542
544 4.1. Data Types
546 Data types defined in the base type library are categorized by types
547 of atomic, compound struct, and compound array.
549 4.1.1. Atomic
551 The following data types are defined as atomic data types and put in
552 the base type library:
554 Data Type Name Brief Description
555 -------------- -----------------
556 IPv4Addr IPv4 address
557 IPv6Addr IPv6 address
558 IEEEMAC IEEE MAC address
559 LANSpeedType LAN speed by value types
560 DuplexType Duplex types
561 PortStatusType The possible types of port status, used for
562 both administrative and operative status.
563 VlanIDType The type of VLAN ID
564 VlanPriorityType The type of VLAN priority
565 SchdDisciplineType Scheduling discipline type
567 4.1.2. Compound Struct
569 The following compound struct types are defined in the base type
570 library:
572 Data Type Name Brief Description
573 -------------- -----------------
574 EtherDispatchEntryType Entry type for Ethernet dispatch table
575 VlanInputTableEntryType Entry type for VLAN input table
576 EncapTableEntryType Entry type for Ethernet encapsulation table
577 MACInStatsType Statistics type for EtherMACIn LFB
578 MACOutStatsType Statistics type for EtherMACOut LFB
579 EtherClassifyStatsType Entry type for statistics table in
580 EtherClassifier LFB.
581 IPv4PrefixInfoType Entry type for IPv4 prefix table
582 IPv6PrefixInfoType Entry type for IPv6 prefix table
583 IPv4NextHopInfoType Entry type for IPv4 next hop table
584 IPv6NextHopInfoType Entry type for IPv6 next hop table
585 IPv4ValidatorStatsType Statistics type in IPv4validator LFB
586 IPv6ValidatorStatsType Statistics type in IPv6validator LFB
587 IPv4UcastLPMStatsType Statistics type in IPv4UcastLPM LFB
588 IPv6UcastLPMStatsType Statistics type in IPv6UcastLPM LFB
589 QueueStatsType Entry type for queue depth table
590 MetadataDispatchType Entry type for metadata dispatch table
592 4.1.3. Compound Array
594 Compound array types are mostly created based on compound struct
595 types for LFB table components. The following compound array types
596 are defined in this base type library:
598 Data Type Name Brief Description
599 -------------- -----------------
600 EtherClassifyStatsTableType Type for Ethernet classifier statistics
601 information table.
602 EtherDispatchTableType Type for Ethernet dispatch table
603 VlanInputTableType Type for VLAN input table
604 EncapTableType Type for Ethernet encapsulation table
605 IPv4PrefixTableType Type for IPv4 prefix table
606 IPv6PrefixTableType Type for IPv6 prefix table
607 IPv4NextHopTableType Type for IPv4 next hop table
608 IPv6NextHopTableType Type for IPv6 next hop table
609 MetadataDispatchTableType Type for Metadata dispatch table
610 QueueStatsTableType Type for Queue depth table
612 4.2. Frame Types
614 According to FE model [RFC5812], frame types are used in LFB
615 definitions to define packet frame types both an LFB expects at its
616 input port and the LFB emits at its output port. The
617 element in the FE model is used to define a new frame type.
619 The following frame types are defined in the base type library:
621 Frame Name Brief Description
622 -------------- ----------------
623 EthernetII An Ethernet II frame
624 ARP An ARP packet frame
625 IPv4 An IPv4 packet frame
626 IPv6 An IPv6 packet frame
627 IPv4Unicast An IPv4 unicast packet frame
628 IPv4Multicast An IPv4 multicast packet frame
629 IPv6Unicast An IPv6 unicast packet frame
630 IPv6Multicast An IPv6 multicast packet frame
631 Arbitrary Any type of packet frames
633 4.3. MetaData Types
635 LFB Metadata is used to communicate per-packet state from one LFB to
636 another. The element in the FE model is used to define
637 a new metadata type.
639 The following metadata types are currently defined in the base type
640 library.
642 Metadata Name Metadata ID Brief Description
643 ------------ ---------- -------------
644 PHYPortID 1 Metadata indicating a physical port ID
645 SrcMAC 2 Metadata indicating a source MAC address
646 DstMAC 3 Metadata indicating a destination MAC
647 address.
648 LogicalPortID 4 Metadata of a logical port ID
649 EtherType 5 Metadata indicating an Ethernet type
650 VlanID 6 Metadata of a VLAN ID
651 VlanPriority 7 Metadata of a VLAN priority
652 NextHopIPv4Addr 8 Metadata representing a next hop IPv4
653 address.
654 NextHopIPv6Addr 9 Metadata representing a next hop IPv6
655 address.
656 HopSelector 10 Metadata indicating a hop selector
657 ExceptionID 11 Metadata indicating exception types for
658 exceptional cases during LFB processing.
659 ValidateErrorID 12 Metadata indicating error types when a
660 packet passes validation process.
661 L3PortID 13 Metadata indicating ID of an L3 logical
662 port.
663 RedirectIndex 14 Metadata that CE sends to RedirectIn LFB,
664 indicating an associated packet a group
665 output port index of the LFB.
666 MediaEncapInfoIndex 15 A search key a packet uses to look up a
667 table in related LFBs to select an
668 encapsulation media.
670 4.4. XML for Base Type Library
672
673
676
677
678 EthernetAll
679 Packet with any Ethernet type
680
681
682 EthernetII
683 Packet with Ethernet II type
684
685
686 ARP
687 ARP packet
688
689
690 IPv4
691 IPv4 packet
692
693
694 IPv6
695 IPv6 packet
696
697
698 IPv4Unicast
699 IPv4 unicast packet
700
701
702 IPv4Multicast
703 IPv4 multicast packet
704
705
706 IPv6Unicast
707 IPv6 unicast packet
708
709
710 IPv6Multicast
711 IPv6 multicast packet
712
713
714 Arbitrary
715 Any type of packet
716
717
718
719
720 IPv4Addr
721 IPv4 address
722 byte[4]
723
724
725 IPv6Addr
726 IPv6 address
727 byte[16]
728
729
730 IEEEMAC
731 IEEE MAC address
732 byte[6]
733
734
735 LANSpeedType
736 LAN speed type
737
738 uint32
739
740
741 LAN_SPEED_NONE
742 Nothing connected
743
744
745 LAN_SPEED_10M
746 10M Ethernet
747
748
749 LAN_SPEED_100M
750 100M Ethernet
751
752
753 LAN_SPEED_1G
754 1G Ethernet
755
756
757 LAN_SPEED_10G
758 10G Ethernet
759
760
761 LAN_SPEED_40G
762 40G Ethernet
763
764
765 LAN_SPEED_100G
766 100G Ethernet
767
768
769 LAN_SPEED_400G
770 400G Ethernet
771
772
773 LAN_SPEED_1T
774 1T Ethernet
775
776
777 LAN_SPEED_OTHER
778 Other LAN speed type
779
780
781 LAN_SPEED_AUTO
782 LAN speed by auto negotiation
783
784
786
787
788
789 DuplexType
790 Duplex mode type
791
792 uint32
793
794
795 Auto
796 Auto negotiation
797
798
799 HalfDuplex
800 Half duplex
801
802
803 FullDuplex
804 Full duplex
805
806
807
808
809
810 PortStatusType
811
812 Type for port status, used for both administrative and
813 operative status.
814
815
816 uchar
817
818
819 Disabled
820 Port disabled
821
822
823 Up
824 Port up
825
826
827 Down
828 Port down
829
830
831
832
833
834 MACInStatsType
835
836 Data type defined for statistics in EtherMACIn LFB.
837
838
839
840 NumPacketsReceived
841 Number of packets received
842 uint64
843
844
845 NumPacketsDropped
846 Number of packets dropped
847 uint64
848
849
850
851
852 MACOutStatsType
853
854 Data type defined for statistics in EtherMACOut LFB.
855
856
857
858 NumPacketsTransmitted
859 Number of packets transmitted
860 uint64
861
862
863 NumPacketsDropped
864 Number of packets dropped
865 uint64
866
867
868
869
870 EtherDispatchEntryType
871
872 Data type defined for entry of Ethernet dispatch
873 table in EtherClassifier LFB.
874
875
876
877 LogicalPortID
878 Logical port ID
879 uint32
880
881
882 EtherType
883
884 The Ethernet type of the Ethernet packet.
885
886 uint16
887
888
889 Reserved
890
891 A reserved bit space mainly for purpose of padding
892 and packing efficiency.
893
894 uint16
895
896
897 LFBOutputSelectIndex
898
899 Index for a packet to select an instance in the
900 group output port of EtherClassifier LFB to output.
901
902 uint32
903
904
905
906
907 EtherDispatchTableType
908
909 Data type defined for Ethernet dispatch table in
910 EtherClassifier LFB. The table is composed of an array
911 of entries with EtherDispatchEntryType data type.
912
913
914 EtherDispatchEntryType
915
916
917
918 VlanIDType
919 Data type for VLAN ID
920
921 uint16
922
923
924
925
926
927
928 VlanPriorityType
929 Data type for VLAN priority
930
931 uchar
932
933
934
935
936
937
938 VlanInputTableEntryType
939
940 Data type for entry of VLAN input table in EtherClassifier
941 LFB. Each entry of the table contains an incoming port ID,
942 a VLAN ID and a logical port ID. Every input packet is
943 assigned with a new logical port ID according to the
944 packet incoming port ID and the VLAN ID.
945
946
947
948 IncomingPortID
949 The incoming port ID
950 uint32
951
952
953 VlanID
954 The VLAN ID
955 VlanIDType
956
957
958 Reserved
959
960 A reserved bit space mainly for purpose of padding
961 and packing efficiency.
962
963 uint16
964
965
966 LogicalPortID
967 The logical port ID
968 uint32
969
970
971
972
973 VlanInputTableType
974
975 Data type for the VLAN input table in EtherClassifier
976 LFB. The table is composed of an array of entries with
977 VlanInputTableEntryType.
979
980
981 VlanInputTableEntryType
982
983
984
985 EtherClassifyStatsType
986
987 Data type for entry of statistics table in EtherClassifier
988 LFB.
989
990
991
992 EtherType
993
994 The Ethernet type of the Ethernet packet.
995
996 uint16
997
998
999 Reserved
1000
1001 A reserved bit space mainly for purpose of padding
1002 and packing efficiency.
1003
1004 uint16
1005
1006
1007 PacketsNum
1008 Packets number
1009 uint64
1010
1011
1012
1013
1014 EtherClassifyStatsTableType
1015
1016 Data type for statistics table in EtherClassifier LFB.
1017
1018
1019 EtherClassifyStatsType
1020
1021
1022
1023 IPv4ValidatorStatsType
1024
1025 Data type for statistics in IPv4validator LFB.
1026
1027
1028
1029 badHeaderPkts
1030 Number of packets with bad header
1031 uint64
1032
1033
1034 badTotalLengthPkts
1035
1036 Number of packets with bad total length
1037
1038 uint64
1039
1040
1041 badTTLPkts
1042 Number of packets with bad TTL
1043 uint64
1044
1045
1046 badChecksumPkts
1047 Number of packets with bad checksum
1048 uint64
1049
1050
1051
1052
1053 IPv6ValidatorStatsType
1054
1055 Data type for statistics in IPv6validator LFB.
1056
1057
1058
1059 badHeaderPkts
1060 Number of packets with bad header
1061 uint64
1062
1063
1064 badTotalLengthPkts
1065
1066 Number of packets with bad total length.
1067
1068 uint64
1069
1070
1071 badHopLimitPkts
1072
1073 Number of packets with bad hop limit.
1074
1075 uint64
1076
1077
1078
1079
1080 IPv4PrefixInfoType
1081 Data type for entry of IPv4 longest prefix match
1082 table in IPv4UcastLPM LFB. The destination IPv4 address
1083 of every input packet is used as a search key to look up
1084 the table to find out a next hop selector.
1085
1086
1087 IPv4Address
1088 The destination IPv4 address
1089 IPv4Addr
1090
1091
1092 Prefixlen
1093 The prefix length
1094
1095 uchar
1096
1097
1098
1099
1100
1101
1102 ECMPFlag
1103 The ECMP flag
1104
1105 boolean
1106
1107
1108 False
1109
1110 ECMP false, indicating the route
1111 does not have multiple next hops.
1112
1113
1114
1115 True
1116
1117 ECMP true, indicating the route
1118 has multiple next hops.
1119
1120
1121
1122
1124
1125
1126 DefaultRouteFlag
1127 Default route flag
1128
1129 boolean
1130
1131
1132 False
1133
1134 Default route false, indicating the
1135 route is not a default route.
1136
1137
1138
1139 True
1140
1141 Default route true, indicating the
1142 route is a default route.
1143
1144
1145
1146
1147
1148
1149 Reserved
1150
1151 A reserved bit space mainly for purpose of padding
1152 and packing efficiency.
1153
1154 uchar
1155
1156
1157 HopSelector
1158
1159 The HopSelector produced by the prefix matching LFB,
1160 which will be output to downstream LFB to find next
1161 hop information.
1162
1163 uint32
1164
1165
1166
1167
1168 IPv4PrefixTableType
1169
1170 Data type for IPv4 longest prefix match table in
1171 IPv4UcastLPM LFB. Entry of the table is
1172 of IPv4PrefixInfoType data type.
1173
1174
1175 IPv4PrefixInfoType
1176
1177
1178
1179 IPv4UcastLPMStatsType
1180
1181 Data type for statistics in IPv4UcastLPM LFB.
1182
1183
1184
1185 InRcvdPkts
1186 Number of received input packets.
1187 uint64
1188
1189
1190 FwdPkts
1191 Number of forwarded packets.
1192 uint64
1193
1194
1195 NoRoutePkts
1196
1197 Number of packets with no route found.
1198
1199 uint64
1200
1201
1202
1203
1204 IPv6PrefixInfoType
1205 Data type for entry of IPv6 longest prefix match
1206 table in IPv6UcastLPM LFB. The destination IPv6 address
1207 of every input packet is used as a search key to look up
1208 the table to find out a next hop selector.
1209
1210
1211 IPv6Address
1212 The destination IPv6 address
1213 IPv6Addr
1214
1215
1216 Prefixlen
1217 The prefix length
1218
1219 uchar
1220
1221
1222
1223
1224
1225
1226 ECMPFlag
1227 ECMP flag
1228
1229 boolean
1230
1231
1232 False
1233 ECMP false
1234
1235
1236 True
1237 ECMP true
1238
1239
1240
1241
1242
1243 DefaultRouteFlag
1244 Default route flag
1245
1246 boolean
1247
1248
1249 False
1250 Default false
1251
1252
1253 True
1254 Default route true
1255
1256
1257
1258
1259
1260 Reserved
1261
1262 A reserved bit space mainly for purpose of padding
1263 and packing efficiency.
1264
1265 uchar
1266
1267
1268 HopSelector
1269
1270 The HopSelector produced by the prefix matching LFB,
1271 which will be output to downstream LFB to find next
1272 hop information.
1273
1274 uint32
1275
1276
1277
1278
1279 IPv6PrefixTableType
1280
1281 Data type for IPv6 longest prefix match table in
1282 IPv6UcastLPM LFB. Entry of the table is
1283 of IPv6PrefixInfoType data type.
1284
1285
1286 IPv6PrefixInfoType
1287
1288
1289
1290 IPv6UcastLPMStatsType
1291 Data type for statistics in IPv6UcastLPM LFB
1292
1293
1294
1295 InRcvdPkts
1296 Number of received input packets
1297 uint64
1298
1299
1300 FwdPkts
1301 Number of forwarded packets
1302 uint64
1303
1304
1305 NoRoutePkts
1306
1307 Number of packets with no route found.
1308
1309 uint64
1310
1311
1312
1313
1314 IPv4NextHopInfoType
1315
1316 Data type for entry of IPv4 next hop information table
1317 in IPv4NextHop LFB. The table uses a hop selector
1318 received from upstream LFB as a search key to look up
1319 index of the table to find the next hop information.
1320
1321
1322
1323 L3PortID
1324
1325 The ID of the logical output port that is to pass
1326 onto downstream LFB, indicating what port to the
1327 neighbor is as defined by L3.
1328
1329 uint32
1330
1331
1332 MTU
1333
1334 Maximum Transmission Unit for outgoing port
1335
1336 uint32
1337
1338
1339 NextHopIPAddr
1340 The next hop IPv4 address
1341 IPv4Addr
1342
1343
1344 MediaEncapInfoIndex
1345
1346 The index passed onto a downstream encapsulation
1347 LFB, used there as a search key to lookup further
1348 encapsulation information.
1349
1350 uint32
1351
1352
1353 LFBOutputSelectIndex
1354
1355 The index for the IPv4NextHop LFB to choose an
1356 instance in the group output port of the LFB to
1357 output.
1358
1359 uint32
1360
1361
1362
1363
1364 IPv4NextHopTableType
1365
1366 Data type for IPv4 next hop table in IPv4NextHop LFB.
1367 Entry of the table is of IPv4NextHopInfoType data type.
1368
1369
1370 IPv4NextHopInfoType
1371
1372
1373
1374 IPv6NextHopInfoType
1375
1376 Data type for entry of IPv6 next hop information table
1377 in IPv6NextHop LFB. The table uses a hop selector
1378 received from upstream LFB as a search key to look up
1379 index of the table to find the next hop information.
1380
1381
1382
1383 L3PortID
1384
1385 The ID of the logical output port that is to pass
1386 onto downstream LFB, indicating what port to the
1387 neighbor is as defined by L3.
1388
1389 uint32
1390
1391
1392 MTU
1393
1394 Maximum Transmission Unit for outgoing port
1395
1396 uint32
1397
1398
1399 NextHopIPAddr
1400 The next hop IPv6 address
1401 IPv6Addr
1402
1403
1404 MediaEncapInfoIndex
1405
1406 The index passed onto a downstream encapsulation
1407 LFB, used there as a search key to lookup further
1408 encapsulation information.
1409
1410 uint32
1411
1412
1413 LFBOutputSelectIndex
1414
1415 The index for the IPv6NextHop LFB to choose an instance
1416 in the group output port of the LFB to output.
1417
1418 uint32
1419
1420
1421
1422
1423 IPv6NextHopTableType
1424
1425 Data type for IPv6 next hop table in IPv6NextHop LFB.
1426 Entry of the table is of IPv6NextHopInfoType data type.
1427
1428
1429 IPv6NextHopInfoType
1430
1431
1432
1433 EncapTableEntryType
1434
1435 Data type for entry of Ethernet encapsulation table in
1436 EtherEncap LFB. The LFB uses the MediaEncapInfoIndex
1437 received from upstream LFB as index of the table to
1438 find encapsulation information of every packet.
1439
1440
1441
1442 DstMac
1443
1444 Destination MAC address for Ethernet encapsulation of
1445 the packet.
1446
1447 IEEEMAC
1448
1449
1450 SrcMac
1451
1452 Source MAC address for Ethernet encapsulation of the
1453 packet.
1454
1455 IEEEMAC
1456
1457
1458 VlanID
1459 The VLAN ID assigned to the packet
1460 VlanIDType
1461
1462
1463 Reserved
1464
1465 A reserved bit space mainly for purpose of padding
1466 and packing efficiency.
1467
1468 uint16
1469
1470
1471 L2PortID
1472
1473 The L2 logical output port ID for the packet.
1474
1475 uint32
1476
1477
1478
1479
1480 EncapTableType
1481
1482 Data type for Ethernet encapsulation table in Etherencap
1483 LFB. Entry of the table is of EncapTableEntryType data
1484 type.
1485
1486
1487 EncapTableEntryType
1488
1489
1490
1491 MetadataDispatchType
1492
1493 Data type for entry of metadata dispatch table used in
1494 BasicMetadataDispatch LFB. The LFB uses a metadata value
1495 as a search key to look up the table to find an index of
1496 the LFB group output port to output the packet.
1497
1498
1499
1500 MetadataValue
1501 The value of the dispatch metadata
1502 uint32
1503
1504
1505 OutputIndex
1506
1507 Index of a group output port for outgoing packets.
1509
1510 uint32
1511
1512
1513
1514
1515 MetadataDispatchTableType
1516
1517 Data type for metadata dispatch table used in
1518 BasicMetadataDispatch LFB. Metadata value of
1519 the table is also defined as a content key field.
1520
1521
1522 MetadataDispatchType
1523
1524 MetadataValue
1525
1526
1527
1528
1529 SchdDisciplineType
1530 Scheduling discipline type
1531
1532 uint32
1533
1534
1535 RR
1536
1537 Round Robin scheduling discipline
1538
1539
1540
1541
1542
1543
1544 QueueStatsType
1545
1546 Data type for entry of queue statistics table in
1547 GenericScheduler LFB.
1548
1549
1550
1551 QueueID
1552 The input queue ID
1553 uint32
1554
1555
1556 QueueDepthInPackets
1557 Current queue depth in packets
1558 uint32
1559
1560
1561 QueueDepthInBytes
1562 Current queue depth in bytes
1563 uint32
1564
1565
1566
1567
1568 QueueStatsTableType
1569
1570 Data type for queue statistics table in GenericScheduler
1571 LFB. Entry of the table is of QueueStatsType data type.
1572
1573
1574 QueueStatsType
1575
1576
1577
1578
1579
1580 PHYPortID
1581 Metadata indicating physical port ID
1582 1
1583 uint32
1584
1585
1586 SrcMAC
1587 Metadata indicating source MAC address
1588 2
1589 IEEEMAC
1590
1591
1592 DstMAC
1593
1594 Metadata indicating destination MAC address.
1595
1596 3
1597 IEEEMAC
1598
1599
1600 LogicalPortID
1601 Metadata of logical port ID
1602 4
1603 uint32
1604
1605
1606 EtherType
1607 Metadata indicating Ethernet type
1608 5
1609 uint16
1610
1611
1612 VlanID
1613 Metadata of VLAN ID
1614 6
1615 VlanIDType
1616
1617
1618 VlanPriority
1619 Metadata of VLAN priority
1620 7
1621 VlanPriorityType
1622
1623
1624 NextHopIPv4Addr
1625
1626 Metadata representing a next hop IPv4 address
1627
1628 8
1629 IPv4Addr
1630
1631
1632 NextHopIPv6Addr
1633
1634 Metadata representing a next hop IPv6 address
1635
1636 9
1637 IPv6Addr
1638
1639
1640 HopSelector
1641 Metadata indicating a hop selector
1642 10
1643 uint32
1644
1645
1646 ExceptionID
1647
1648 Metadata indicating exception types for exceptional cases
1649 during packet processing.
1650
1651 11
1652
1653 uint32
1654
1655
1656 AnyUnrecognizedExceptionCase
1657 Any unrecognized exception case
1658
1659
1660 ClassifyNoMatching
1661
1662 Exception case: no matching of tables in
1663 EtherClassifier LFB.
1664
1665
1666
1667 MediaEncapInfoIndexInvalid
1668
1669 Exception case: the MediaEncapInfoIndex value of
1670 the packet is invalid and cannot be allocated in
1671 the EncapTable in EtherEncap LFB.
1672
1673
1674
1675 EncapTableLookupFailed
1676
1677 Exception case: the packet fails lookup of the
1678 EncapTable table in EtherEncap LFB even though the
1679 MediaEncapInfoIndex is valid.
1680
1681
1682
1683 BadTTL
1684
1685 Exception case: packet with expired TTL
1686
1687
1688
1689 IPv4HeaderLengthMismatch
1690
1691 Exception case: packet with header length more
1692 than 5 words.
1693
1694
1695
1696 RouterAlertOptions
1697
1698 Exception case: packet IP head includes router
1699 alert options.
1700
1702
1703
1704 IPv6HopLimitZero
1705
1706 Exception case: packet with the hop limit to zero.
1707
1708
1709
1710 IPv6NextHeaderHBH
1711
1712 Exception case: packet with next header set to
1713 Hop-by-Hop.
1714
1715
1716
1717 SrcAddressExecption
1718
1719 Exception case: packet with exceptional source
1720 address.
1721
1722
1723
1724 DstAddressExecption
1725
1726 Exception case: packet with exceptional destination
1727 address.
1728
1729
1730
1731 LPMLookupFailed
1732
1733 Exception case: packet failed the LPM table lookup
1734 in a prefix match LFB.
1735
1736
1737
1738 HopSelectorInvalid
1739
1740 Exception case: HopSelector for the packet is
1741 invalid.
1742
1743
1744
1745 NextHopLookupFailed
1746
1747 Exception case: packet failed lookup of a next hop
1748 table even though HopSelector is valid.
1749
1751
1752
1753 FragRequired
1754
1755 Exception case: packet fragmentation is required
1756
1757
1758
1759 MetadataNoMatching
1760
1761 Exception case: there is no matching when looking
1762 up the metadata dispatch table in
1763 BasicMetadataDispatch LFB.
1764
1765
1766
1767
1768
1769
1770 ValidateErrorID
1771
1772 Metadata indicating error types when a packet passes
1773 validation process.
1774
1775 12
1776
1777 uint32
1778
1779
1780 AnyUnrecognizedValidateErrorCase
1781
1782 Any unrecognized validate error case.
1783
1784
1785
1786 InvalidIPv4PacketSize
1787
1788 Error case: packet length reported by the link
1789 layer is less than 20 bytes.
1790
1791
1792
1793 NotIPv4Packet
1794
1795 Error case: packet is not IP version 4
1796
1797
1798 InvalidIPv4HeaderLengthSize
1799
1800 Error case: packet with header length field in
1801 the header less than 5 words.
1802
1803
1804
1805 InvalidIPv4LengthFieldSize
1806
1807 Error case: packet with total length field in the
1808 header less than 20 bytes.
1809
1810
1811
1812 InvalidIPv4Checksum
1813
1814 Error case: packet with invalid checksum.
1815
1816
1817
1818 InvalidIPv4SrcAddr
1819
1820 Error case: packet with invalid IPv4 source
1821 address.
1822
1823
1824
1825 InvalidIPv4DstAddr
1826
1827 Error case: packet with invalid IPv4 destination
1828 address.
1829
1830
1831
1832 InvalidIPv6PacketSize
1833
1834 Error case: packet size is less than 40 bytes.
1835
1836
1837
1838 NotIPv6Packet
1839
1840 Error case: packet is not IP version 6
1841
1842
1843
1844 InvalidIPv6SrcAddr
1845
1846 Error case: packet with invalid IPv6 source address.
1848
1849
1850
1851 InvalidIPv6DstAddr
1852
1853 Error case: packet with invalid IPv6 destination
1854 address.
1855
1856
1857
1858
1859
1860
1861 L3PortID
1862
1863 Metadata indicating ID of an L3 logical port
1864
1865 13
1866 uint32
1867
1868
1869 RedirectIndex
1870
1871 Metadata that CE sends to RedirectIn LFB, indicating
1872 the index of the LFB group output port.
1873
1874 14
1875 uint32
1876
1877
1878 MediaEncapInfoIndex
1879
1880 A search key a packet uses to look up a table to select
1881 an encapsulation media.
1882
1883 15
1884 uint32
1885
1886
1887
1888 5. LFB Class Description
1890 According to ForCES specifications, LFB (Logical Function Block) is a
1891 well defined, logically separable functional block that resides in an
1892 FE, and is a functionally accurate abstraction of the FE's processing
1893 capabilities. An LFB Class (or type) is a template that represents a
1894 fine-grained, logically separable aspect of FE processing. Most LFBs
1895 are related to packet processing in the data path. LFB classes are
1896 the basic building blocks of the FE model. Note that [RFC5810] has
1897 already defined an 'FE Protocol LFB' which is a logical entity in
1898 each FE to control the ForCES protocol. [RFC5812] has already
1899 defined an 'FE Object LFB'. Information like the FE Name, FE ID, FE
1900 State, LFB Topology in the FE are represented in this LFB.
1902 As specified in Section 3.1, this document focuses on the base LFB
1903 library for implementing typical router functions, especially for IP
1904 forwarding functions. As a result, LFB classes in the library are
1905 all base LFBs to implement router forwarding.
1907 In this section, the terms "upstream LFB" and "downstream LFB" are
1908 used. These are used relative to an LFB to an LFB that is being
1909 described. An "upstream LFB" is one whose output ports are connected
1910 to input ports of the LFB under consideration such that output
1911 (typically packets with metadata) can be sent from the "upstream LFB"
1912 to the LFB under consideration. Similarly, a "downstream LFB" whose
1913 input ports are connected to output ports of the LFB under
1914 consideration such that the LFB under consideration can send
1915 information to the "downstream LFB". Note that in some rare
1916 topologies, an LFB may be both upstream and downstream relative to
1917 another LFB.
1919 Also note that, as a default provision of [RFC5812], in FE model, all
1920 metadata produced by upstream LFBs will pass through all downstream
1921 LFBs by default without being specified by input port or output port.
1922 Only those metadata that will be used (consumed) by an LFB will be
1923 explicitly marked in input of the LFB as expected metadata. For
1924 instance, in downstream LFBs of a physical layer LFB, even there is
1925 no specific metadata expected, metadata like PHYPortID produced by
1926 the physical layer LFB will always pass through all downstream LFBs
1927 regardless of whether the metadata has been expected by the LFBs or
1928 not.
1930 5.1. Ethernet Processing LFBs
1932 As the most popular physical and data link layer protocols, Ethernet
1933 is widely deployed. It becomes a basic requirement for a router to
1934 be able to process various Ethernet data packets.
1936 Note that there exist different versions of Ethernet formats, like
1937 Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP.
1938 There also exist varieties of LAN techniques based on Ethernet, like
1939 various VLANs, MACinMAC, etc. Ethernet processing LFBs defined here
1940 are intended to be able to cope with all these variations of Ethernet
1941 technology.
1943 There are also various types of Ethernet physical interface media.
1944 Among them, copper and fiber media may be the most popular ones. As
1945 a base LFB definition and a starting point, the document only defines
1946 an Ethernet physical LFB with copper media. For other media
1947 interfaces, specific LFBs may be defined in the future versions of
1948 the library.
1950 5.1.1. EtherPHYCop
1952 EtherPHYCop LFB abstracts an Ethernet interface physical layer with
1953 media limited to copper.
1955 5.1.1.1. Data Handling
1957 This LFB is the interface to the Ethernet physical media. The LFB
1958 handles Ethernet frames coming in from or going out of the FE.
1959 Ethernet frames sent and received cover all packets encapsulated with
1960 different versions of Ethernet protocols, like Ethernet V2, 802.3
1961 RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets
1962 encapsulated with varieties of LAN techniques based on Ethernet, like
1963 various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll
1964 frame type has been introduced.
1966 Ethernet frames are received from the physical media port and passed
1967 downstream to LFBs such as EtherMACIn via a singleton output known as
1968 "EtherPHYOut". A 'PHYPortID' metadata, to indicate which physical
1969 port the frame came into from the external world, is passed along
1970 with the frame.
1972 Ethernet packets are received by this LFB from upstream LFBs such as
1973 EtherMacOut LFBs via the singleton input known as "EtherPHYIn" before
1974 being sent out onto the external world.
1976 5.1.1.2. Components
1978 The AdminStatus component is defined for CE to administratively
1979 manage the status of the LFB. The CE may administratively startup or
1980 shutdown the LFB by changing the value of AdminStatus. The default
1981 value is set to 'Down'.
1983 An OperStatus component captures the physical port operational
1984 status. A PHYPortStatusChanged event is defined so the LFB can
1985 report to the CE whenever there is an operational status change of
1986 the physical port.
1988 The PHYPortID component is a unique identification for a physical
1989 port. It is defined as 'read-only' by CE. Its value is enumerated
1990 by FE. The component will be used to produce a 'PHYPortID' metadata
1991 at the LFB output and to associate it to every Ethernet packet this
1992 LFB receives. The metadata will be handed to downstream LFBs for
1993 them to use the PHYPortID.
1995 A group of components are defined for link speed management. The
1996 AdminLinkSpeed is for CE to configure link speed for the port and the
1997 OperLinkSpeed is for CE to query the actual link speed in operation.
1998 The default value for the AdminLinkSpeed is set to auto-negotiation
1999 mode.
2001 A group of components are defined for duplex mode management. The
2002 AdminDuplexMode is for CE to configure proper duplex mode for the
2003 port and the OperDuplexMode is for CE to query the actual duplex mode
2004 in operation. The default value for the AdminDuplexMode is set to
2005 auto-negotiation mode.
2007 A CarrierStatus component captures the status of the carrier and
2008 specifies whether the port link is operationally up. The default
2009 value for the CarrierStatus is 'false'.
2011 5.1.1.3. Capabilities
2013 The capability information for this LFB includes the link speeds that
2014 are supported by the FE (SupportedLinkSpeed) as well as the supported
2015 duplex modes (SupportedDuplexMode).
2017 5.1.1.4. Events
2019 Several events are generated. There is an event for changes in the
2020 status of the physical port (PhyPortStatusChanged). Such an event
2021 will notify that the physical port status has been changed and the
2022 report will include the new status of the physical port.
2024 Another event captures changes in the operational link speed
2025 (LinkSpeedChanged). Such an event will notify the CE that the
2026 operational speed has been changed and the report will include the
2027 new negotiated operational speed.
2029 A final event captures changes in the duplex mode
2030 (DuplexModeChanged). Such an event will notify the CE that the
2031 duplex mode has been changed and the report will include the new
2032 negotiated duplex mode.
2034 5.1.2. EtherMACIn
2036 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer.
2037 This LFB describes Ethernet processing functions like MAC address
2038 locality check, deciding if the Ethernet packets should be bridged,
2039 providing Ethernet layer flow control, etc.
2041 5.1.2.1. Data Handling
2043 The LFB is expected to receive all types of Ethernet packets, via a
2044 singleton input known as "EtherPktsIn", which are usually output from
2045 some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside
2046 with a metadata indicating the physical port ID that the packet
2047 arrived on.
2049 The LFB is defined with two separate singleton outputs. All Output
2050 packets are emitted in the original Ethernet format received at the
2051 physical port, unchanged, and cover all types of Ethernet types.
2053 The first singleton output is known as "NormalPathOut". It usually
2054 outputs Ethernet packets to some LFB like an EtherClassifier LFB for
2055 further L3 forwarding process alongside with a PHYPortID metadata
2056 indicating which physical port the packet came from.
2058 The second singleton output is known as "L2BridgingPathOut".
2059 Although the LFB library this document defines is basically to meet
2060 typical router functions, it will attempt to be forward compatible
2061 with future router functions. The "L2BridgingPathOut" is defined to
2062 meet the requirement that L2 bridging functions may be optionally
2063 supported simultaneously with L3 processing and some L2 bridging LFBs
2064 that may be defined in the future. If the FE supports L2 bridging,
2065 the CE can enable or disable it by means of a "L2BridgingPathEnable"
2066 component in the FE. If it is enabled, by also instantiating some L2
2067 bridging LFB instances following the L2BridgingPathOut, FEs are
2068 expected to fulfill L2 bridging functions. L2BridgingPathOut will
2069 output packets exactly the same as that in the NormalPathOut output.
2071 This LFB can be set to work in a Promiscuous Mode, allowing all
2072 packets to pass through the LFB without being dropped. Otherwise, a
2073 locality check will be performed based on the local MAC addresses.
2074 All packets that do not pass through the locality check will be
2075 dropped.
2077 This LFB can optionally participate in Ethernet flow control in
2078 cooperation with EtherMACOut LFB. This document does not go into the
2079 details of how this is implemented. This document also does not
2080 describe how the buffers which induce the flow control messages
2081 behave - it is assumed that such artifacts exist and describing them
2082 is out of scope in this document.
2084 5.1.2.2. Components
2086 The AdminStatus component is defined for the CE to administratively
2087 manage the status of the LFB. The CE may administratively startup or
2088 shutdown the LFB by changing the value of AdminStatus. The default
2089 value is set to 'Down'.
2091 The LocalMACAddresses component specifies the local MAC addresses
2092 based on which locality checks will be made. This component is an
2093 array of MAC addresses, and of 'read-write' access permission.
2095 An L2BridgingPathEnable component captures whether the LFB is set to
2096 work as a L2 bridge. An FE that does not support bridging will
2097 internally set this flag to false, and additionally set the flag
2098 property as read-only. The default value for the component is
2099 'false'.
2101 The PromiscuousMode component specifies whether the LFB is set to
2102 work as in a promiscuous mode. The default value for the component
2103 is 'false'.
2105 The TxFlowControl component defines whether the LFB is performing
2106 flow control on sending packets. The default value is 'false'. Note
2107 that the component is defined as "optional". If an FE does not
2108 implement the component while a CE try to configure the component to
2109 this FE, an error from FE may be responded to CE with error code
2110 like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or 0x15(E_NOT_SUPPORTED)
2111 depending on the FE processing. See [RFC5810] for details.
2113 The RxFlowControl component defines whether the LFB is performing
2114 flow control on receiving packets. The default value is 'false'.The
2115 component is also defined as "optional" one.
2117 A struct component, MACInStats, defines a set of statistics for this
2118 LFB, including the number of received packets and the number of
2119 dropped packets. Note that this statistics component is optional to
2120 implementers. If a CE tries to query the componennt while it is not
2121 implemented in an FE, an error code will be responded to CE
2122 indicating the error type like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or
2123 0x15(E_NOT_SUPPORTED), depending on the FE implementation.
2125 5.1.2.3. Capabilities
2127 This LFB does not have a list of capabilities.
2129 5.1.2.4. Events
2131 This LFB does not have any events specified.
2133 5.1.3. EtherClassifier
2135 EtherClassifier LFB abstracts the process to decapsulate Ethernet
2136 packets and then classify them.
2138 5.1.3.1. Data Handling
2140 This LFB describes the process of decapsulating Ethernet packets and
2141 classifying them into various network layer data packets according to
2142 information included in the Ethernet packets headers.
2144 The LFB is expected to receive all types of Ethernet packets, via a
2145 singleton input known as "EtherPktsIn", which are usually output from
2146 an upstream LFB like EtherMACIn LFB. This input is also capable of
2147 multiplexing to allow for multiple upstream LFBs being connected.
2148 For instance, when L2 bridging function is enabled in EtherMACIn LFB,
2149 some L2 bridging LFBs may be applied. In this case, some Ethernet
2150 packets after L2 processing may have to be input to EtherClassifier
2151 LFB for classification, while simultaneously packets directly output
2152 from EtherMACIn may also need to input to this LFB. This input is
2153 capable of handling such a case. Usually, all expected Ethernet
2154 Packets will be associated with a PHYPortID metadata, indicating the
2155 physical port the packet comes from. In some cases, for instance,
2156 like in a MACinMAC case, a LogicalPortID metadata may be expected to
2157 associate with the Ethernet packet to further indicate which logical
2158 port the Ethernet packet belongs to. Note that PHYPortID metadata is
2159 always expected while LogicalPortID metadata is optionally expected.
2161 Two output LFB ports are defined.
2163 The first output is a group output port known as "ClassifyOut".
2164 Types of network layer protocol packets are output to instances of
2165 the port group. Because there may be various type of protocol
2166 packets at the output ports, the produced output frame is defined as
2167 arbitrary for the purpose of wide extensibility in the future.
2168 Metadata to be carried along with the packet data is produced at this
2169 LFB for consumption by downstream LFBs. The metadata passed
2170 downstream includes PHYPortID, as well as information on Ethernet
2171 type, source MAC address, destination MAC address and the logical
2172 port ID. If the original packet is a VLAN packet and contains a VLAN
2173 ID and a VLAN priority value, then the VLAN ID and the VLAN priority
2174 value are also carried downstream as metadata. As a result, the VLAN
2175 ID and priority metadata are defined with the availability of
2176 "conditional".
2178 The second output is a singleton output port known as "ExceptionOut",
2179 which will output packets for which the data processing failed, along
2180 with an additional ExceptionID metadata to indicate what caused the
2181 exception. Currently defined exception types include:
2183 o There is no matching when classifying the packet.
2185 Usually the exception out port may point to no where, indicating
2186 packets with exceptions are dropped, while in some cases, the output
2187 may be pointed to the path to the CE for further processing,
2188 depending on individual implementations.
2190 5.1.3.2. Components
2192 An EtherDispatchTable array component is defined in the LFB to
2193 dispatch every Ethernet packet to the output group according to the
2194 logical port ID assigned by the VlanInputTable to the packet and the
2195 Ethernet type in the Ethernet packet header. Each row of the array
2196 is a struct containing a Logical Port ID, an EtherType and an Output
2197 Index. With the CE configuring the dispatch table, the LFB can be
2198 expected to classify various network layer protocol type packets and
2199 output them at different output ports. It is expected that the LFB
2200 classify packets according to protocols like IPv4, IPv6, MPLS, ARP,
2201 ND, etc.
2203 A VlanInputTable array component is defined in the LFB to classify
2204 VLAN Ethernet packets. Each row of the array is a struct containing
2205 an Incoming Port ID, a VLAN ID and a Logical Port ID. According to
2206 IEEE VLAN specifications, all Ethernet packets can be recognized as
2207 VLAN types by defining that if there is no VLAN encapsulation in a
2208 packet, a case with VLAN tag 0 is considered. Every input packet is
2209 assigned with a new LogicalPortID according to the packet incoming
2210 port ID and the VLAN ID. A packet incoming port ID is defined as a
2211 logical port ID if a logical port ID is associated with the packet,
2212 or a physical port ID if no logical port ID associated. The VLAN ID
2213 is exactly the VLAN ID in the packet if it is a VLAN packet, or 0 if
2214 it is not. Note that a logical port ID of a packet may be rewritten
2215 with a new one by the VlanInputTable processing.
2217 Note that the logical port ID and physical port ID mentioned above
2218 are all originally configured by CE, and are globally effective
2219 within a ForCES NE (Network Element). To distinguish a physical port
2220 ID from a logical port ID in the incoming port ID field of the
2221 VlanInputTable, physical port ID and logical port ID must be assigned
2222 with separate number spaces.
2224 An array component, EtherClassifyStats, defines a set of statistics
2225 for this LFB, measuring the number of packets per EtherType. Each
2226 row of the array is a struct containing an EtherType and a Packet
2227 number.Note that this statistics component is optional to
2228 implementers.
2230 5.1.3.3. Capabilities
2232 This LFB does not have a list of capabilities.
2234 5.1.3.4. Events
2236 This LFB has no events specified.
2238 5.1.4. EtherEncap
2240 The EtherEncap LFB abstracts the process to replace or attach
2241 appropriate Ethernet headers to the packet.
2243 5.1.4.1. Data Handling
2245 This LFB abstracts the process of encapsulating Ethernet headers onto
2246 received packets. The encapsulation is based on passed metadata.
2248 The LFB is expected to receive IPv4 and IPv6 packets, via a singleton
2249 input port known as "EncapIn" which may be connected to an upstream
2250 LFB like an IPv4NextHop, an IPv6NextHop, BasicMetadataDispatch, or
2251 any LFB which requires to output packets for Ethernet encapsulation.
2252 The LFB always expects from upstream LFBs the MediaEncapInfoIndex
2253 metadata which is used as a search key to lookup the encapsulation
2254 table EncapTable by the search key matching the table index. An
2255 input packet may also optionally receive a VLAN priority metadata,
2256 indicating that the packet is originally with a priority value. The
2257 priority value will be loaded back to the packet when encapsulating.
2258 The optional VLAN priority metadata is defined with a default value
2259 0.
2261 Two singleton output LFB ports are defined.
2263 The first singleton output known as "SuccessOut". Upon a successful
2264 table lookup, the destination and source MAC addresses, and the
2265 logical media port (L2PortID) are found in the matching table entry.
2266 The CE may set the VlanID in case VLANs are used. By default the
2267 table entry for VlanID of 0 is used as per IEEE rules. Whatever the
2268 value of VlanID is, if the input metadata VlanPriority is non-zero,
2269 the packet will have a VLAN tag. If the VlanPriority and the VlanID
2270 are all zero, there is no VLAN tag to this packet. After replacing
2271 or attaching the appropriate Ethernet headers to the packet is
2272 complete, the packet is passed out on the "SuccessOut" LFB port to a
2273 downstream LFB instance alongside with the L2PortID.
2275 The second singleton output known as "ExceptionOut", which will
2276 output packets for which the table lookup fails, along with an
2277 additional ExceptionID metadata. Currently defined exception types
2278 only include the following case:
2280 o The MediaEncapInfoIndex value of the packet is invalid and can not
2281 be allocated in the EncapTable.
2283 o The packet failed lookup of the EncapTable table even though the
2284 MediaEncapInfoIndex is valid.
2286 The upstream LFB may be programmed by the CE to pass along a
2287 MediaEncapInfoIndex that does not exist in the EncapTable. That is
2288 to allow for resolution of the L2 headers, if needed, to be made at
2289 the L2 encapsulation level in this case (Ethernet) via ARP, or ND (or
2290 other methods depending on the link layer technology) when a table
2291 miss occurs.
2293 For neighbor L2 header resolution(table miss exception), the
2294 processing LFB may pass this packet to the CE via the redirect LFB or
2295 FE software or another LFB instance for further resolution. In such
2296 a case the metadata NextHopIPv4Addr or NextHopIPv6Addr generated by
2297 next hop LFB is also passed to the exception handling. Such an IP
2298 address could be used to do activities such as ARP or ND by the
2299 handler it is passed to.
2301 The result of the L2 resolution is to update the EncapTable as well
2302 as the next hop LFB so subsequent packets do not fail EncapTable
2303 lookup. The EtherEncap LFB does not make any assumptions of how the
2304 EncapTable is updated by the CE (or whether ARP/ND is used
2305 dynamically or static maps exist).
2307 Downstream LFB instances could be either an EtherMACOut type or a
2308 BasicMetadataDispatch type. If the final packet L2 processing is
2309 possible to be on per-media-port basis or resides on a different FE
2310 or in cases where L2 header resolution is needed, then the model
2311 makes sense to use a BasicMetadataDispatch LFB to fan out to
2312 different LFB instances. If there is a direct egress port point,
2313 then the model makes sense to have a downstream LFB instance being an
2314 EtherMACOut.
2316 5.1.4.2. Components
2318 This LFB has only one component named EncapTable which is defined as
2319 an array. Each row of the array is a struct containing the
2320 destination MAC address, the source MAC address, the VLAN ID with a
2321 default value of zero and the output logical L2 port ID.
2323 5.1.4.3. Capabilities
2325 This LFB does not have a list of capabilities.
2327 5.1.4.4. Events
2329 This LFB does not have any events specified.
2331 5.1.5. EtherMACOut
2333 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer.
2334 This LFB describes Ethernet packet output process. Ethernet output
2335 functions are closely related to Ethernet input functions, therefore
2336 many components defined in this LFB are as aliases of EtherMACIn LFB
2337 components.
2339 5.1.5.1. Data Handling
2341 The LFB is expected to receive all types of Ethernet packets, via a
2342 singleton input known as "EtherPktsIn", which are usually output from
2343 an Ethernet encapsulation LFB, alongside with a metadata indicating
2344 the physical port ID that the packet will go through.
2346 The LFB is defined with a singleton output port known as
2347 "EtherPktsOut". All Output packets are in Ethernet format, possibly
2348 with various Ethernet types, alongside with a metadata indicating the
2349 physical port ID the packet is to go through. This output links to a
2350 downstream LFB that is usually an Ethernet physical LFB like
2351 EtherPHYcop LFB.
2353 This LFB can optionally participate in Ethernet flow control in
2354 cooperation with EtherMACIn LFB. This document does not go into the
2355 details of how this is implemented. This document also does not
2356 describe how the buffers which induce the flow control messages
2357 behave - it is assumed that such artifacts exist and describing them
2358 is out of scope in this document.
2360 Note that as a base definition, functions like multiple virtual MAC
2361 layers are not supported in this LFB version. It may be supported in
2362 the future by defining a subclass or a new version of this LFB.
2364 5.1.5.2. Components
2366 The AdminStatus component is defined for CE to administratively
2367 manage the status of the LFB. The CE may administratively startup or
2368 shutdown the LFB by changing the value of AdminStatus. The default
2369 value is set to 'Down'. Note that this component is defined as an
2370 alias of the AdminStatus component in the EtherMACIn LFB. This
2371 infers that an EtherMACOut LFB usually coexists with an EtherMACIn
2372 LFB, both of which share the same administrative status management by
2373 CE. Alias properties as defined in the ForCES FE model [RFC5812]
2374 will be used by CE to declare the target component this alias refers,
2375 which include the target LFB class and instance IDs as well as the
2376 path to the target component.
2378 The MTU component defines the maximum transmission unit.
2380 The optinal TxFlowControl component defines whether the LFB is
2381 performing flow control on sending packets. The default value is
2382 'false'. Note that this component is defined as an alias of
2383 TxFlowControl component in the EtherMACIn LFB.
2385 The optional RxFlowControl component defines whether the LFB is
2386 performing flow control on receiving packets. The default value is
2387 'false'. Note that this component is defined as an alias of
2388 RxFlowControl component in the EtherMACIn LFB.
2390 A struct component, MACOutStats, defines a set of statistics for this
2391 LFB, including the number of transmitted packets and the number of
2392 dropped packets. This statistics component is optional to
2393 impleneters.
2395 5.1.5.3. Capabilities
2397 This LFB does not have a list of capabilities.
2399 5.1.5.4. Events
2401 This LFB does not have any events specified.
2403 5.2. IP Packet Validation LFBs
2405 The LFBs are defined to abstract IP packet validation process. An
2406 IPv4Validator LFB is specifically for IPv4 protocol validation and an
2407 IPv6Validator LFB for IPv6.
2409 5.2.1. IPv4Validator
2411 The IPv4Validator LFB performs IPv4 packets validation.
2413 5.2.1.1. Data Handling
2415 This LFB performs IPv4 validation according to [RFC1812] and its
2416 updates. The IPv4 packet will be output to the corresponding LFB
2417 port the indication whether the packet is unicast, multicast or
2418 whether an exception has occurred or the validation failed.
2420 This LFB always expects, as input, packets which have been indicated
2421 as IPv4 packets by an upstream LFB, like an EtherClassifier LFB.
2422 There is no specific metadata expected by the input of the LFB.
2424 Four output LFB ports are defined.
2426 All validated IPv4 unicast packets will be output at the singleton
2427 port known as "IPv4UnicastOut". All validated IPv4 multicast packets
2428 will be output at the singleton port known as "IPv4MulticastOut"
2429 port.
2431 A singleton port known as "ExceptionOut" is defined to output packets
2432 which have been validated as exception packets. An exception ID
2433 metadata is produced to indicate what has caused the exception. An
2434 exception case is the case when a packet needs further processing
2435 before being normally forwarded. Currently defined exception types
2436 include:
2438 o Packet with expired TTL
2440 o Packet with header length more than 5 words
2442 o Packet IP head including Router Alert options
2444 o Packet with exceptional source address
2446 o Packet with exceptional destination address
2448 Note that although TTL is checked in this LFB for validity,
2449 operations like TTL decrement are made by the downstream forwarding
2450 LFB.
2452 The final singleton port known as "FailOut" is defined for all
2453 packets which have errors and failed the validation process. An
2454 error case is the case when a packet is unable to be further
2455 processed nor forwarded except being dropped. An error ID is
2456 associated a packet to indicate the failure reason. Currently
2457 defined failure reasons include:
2459 o Packet with size reported less than 20 bytes
2461 o Packet with version is not IPv4
2463 o Packet with header length less than 5 words
2465 o Packet with total length field less than 20 bytes
2467 o Packet with invalid checksum
2469 o Packet with invalid source address
2471 o Packet with invalid destination address
2473 5.2.1.2. Components
2475 This LFB has only one struct component, the
2476 IPv4ValidatorStatisticsType, which defines a set of statistics for
2477 validation process, including the number of bad header packets, the
2478 number of bad total length packets, the number of bad TTL packets,
2479 and the number of bad checksum packets. This statistics componennt
2480 is optional to implementers.
2482 5.2.1.3. Capabilities
2484 This LFB does not have a list of capabilities
2486 5.2.1.4. Events
2488 This LFB does not have any events specified.
2490 5.2.2. IPv6Validator
2492 The IPv6Validator LFB performs IPv6 packets validation.
2494 5.2.2.1. Data Handling
2496 This LFB performs IPv6 validation according to [RFC2460] and its
2497 updates. Then the IPv6 packet will be output to the corresponding
2498 port regarding of the validation result, whether the packet is a
2499 unicast or a multicast one, an exception has occurred or the
2500 validation failed.
2502 This LFB always expects, as input, packets which have been indicated
2503 as IPv6 packets by an upstream LFB, like an EtherClassifier LFB.
2504 There is no specific metadata expected by the input of the LFB.
2506 Similar to the IPv4validator LFB, IPv6Validator LFB has also defined
2507 four output ports to emit packets with various validation results.
2509 All validated IPv6 unicast packets will be output at the singleton
2510 port known as "IPv6UnicastOut". All validated IPv6 multicast packets
2511 will be output at the singleton port known as "IPv6MulticastOut"
2512 port. There is no metadata produced at this LFB.
2514 A singleton port known as "ExceptionOut" is defined to output packets
2515 which have been validated as exception packets. An exception case is
2516 the case when a packet needs further processing before being normally
2517 forwarded. An exception ID metadata is produced to indicate what
2518 caused the exception. Currently defined exception types include:
2520 o Packet with hop limit to zero
2522 o Packet with next header set to Hop-by-Hop
2524 o Packet with exceptional source address
2526 o Packet with exceptional destination address
2528 The final singleton port known as "FailOut" is defined for all
2529 packets which have errors and failed the validation process. An
2530 error case is the case when a packet is unable to be further
2531 processed nor forwarded except being dropped. A validate error ID is
2532 associated to every failed packet to indicate the reason. Currently
2533 defined reasons include:
2535 o Packet with size reported less than 40 bytes
2537 o Packet with not IPv6 version
2539 o Packet with invalid source address
2541 o Packet with invalid destination address
2543 Note that in the base type library, definitions for exception ID and
2544 validate error ID metadata are applied to both IPv4Validator and
2545 IPv6Validator LFBs, i.e., the two LFBs share the same medadata
2546 definition, with different ID assignment inside.
2548 5.2.2.2. Components
2550 This LFB has only one struct component, the
2551 IPv6ValidatorStatisticsType, which defines a set of statistics for
2552 validation process, including the number of bad header packets, the
2553 number of bad total length packets, and the number of bad hop limit
2554 packets. Note that this component is optional to implementers.
2556 5.2.2.3. Capabilities
2558 This LFB does not have a list of capabilities
2560 5.2.2.4. Events
2562 This LFB does not have any events specified.
2564 5.3. IP Forwarding LFBs
2566 IP Forwarding LFBs are specifically defined to abstract the IP
2567 forwarding processes. As definitions for a base LFB library, this
2568 document restricts its LFB definition scope only to IP unicast
2569 forwarding. IP multicast may be defined in future documents.
2571 The two fundamental tasks performed in IP unicast forwarding
2572 constitute looking up the forwarding information table to find next
2573 hop information, and then using the resulting next hop details to
2574 forward packets out on specific physical output ports. This document
2575 models the forwarding processes by abstracting out the described two
2576 steps. Whereas this document describes functional LFB models which
2577 are modular, there may be multiple ways to implement the abstracted
2578 models. It is not intended nor expected that the provided LFB models
2579 constrain implementations.
2581 Based on the IP forwarding abstraction, two kind of typical IP
2582 unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next
2583 hop application LFB. They are further distinguished by IPv4 and IPv6
2584 protocols.
2586 5.3.1. IPv4UcastLPM
2588 The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match
2589 (LPM) process.
2591 This LFB also provides facilities to support users to implement
2592 equal-cost multi-path routing (ECMP) or reverse path forwarding
2593 (RPF). However, this LFB itself does not provide ECMP or RPF. To
2594 fully implement ECMP or RPF, additional specific LFBs, like a
2595 specific ECMP LFB or an RPF LFB, will have to be defined.
2597 5.3.1.1. Data Handling
2599 This LFB performs the IPv4 unicast LPM table looking up. It always
2600 expects as input IPv4 unicast packets from one singleton input known
2601 as "PktsIn". Then the LFB uses the destination IPv4 address of every
2602 packet as search key to look up the IPv4 prefix table and generate a
2603 hop selector as the matching result. The hop selector is passed as
2604 packet metadata to downstream LFBs, and will usually be used there as
2605 a search index to find more next hop information.
2607 Three singleton output LFB ports are defined.
2609 The first singleton output known as "NormalOut" outputs IPv4 unicast
2610 packets that succeed the LPM lookup and (got a hop selector). The
2611 hop selector is associated with the packet as a metadata. Downstream
2612 from the LPM LFB is usually a next hop application LFB, like an
2613 IPv4NextHop LFB.
2615 The second singleton output known as "ECMPOut" is defined to provide
2616 support for users wishing to implement ECMP.
2618 An ECMP flag is defined in the LPM table to enable the LFB to support
2619 ECMP. When a table entry is created with the flag set true, it
2620 indicates this table entry is for ECMP only. A packet, which has
2621 passed through this prefix lookup, will always output from "ECMPOut"
2622 output port, with the hop selector being its lookup result. The
2623 output will usually directly go to a downstream ECMP processing LFB,
2624 where the hop selector can usually further generate optimized one or
2625 multiple next hop routes by use of ECMP algorithms.
2627 A default route flag is defined in the LPM table to enable the LFB to
2628 support a default route as well as loose RPF. When this flag is set
2629 true, the table entry is identified a default route which also
2630 implies that the route is forbidden for RPF. If a user wants to
2631 implement RPF on FE, a specific RPF LFB will have to be defined. In
2632 such RPF LFB, a component can be defined as an alias of the prefix
2633 table component of this LFB as described below.
2635 The final singleton output is known as "ExceptionOut" and is defined
2636 to allow exception packets to output here, along with an ExceptionID
2637 metadata to indicate what caused the exception. Currently defined
2638 exception types include:
2640 o The packet failed the LPM lookup of the prefix table.
2642 The upstream LFB of this LFB is usually IPv4Validator LFB. If RPF is
2643 to be adopted, the upstream can be an RPF LFB, when defined.
2645 The downstream LFB is usually IPv4NextHop LFB. If ECMP is adopted,
2646 the downstream can be an ECMP LFB, when defined.
2648 5.3.1.2. Components
2650 This LFB has two components.
2652 The IPv4PrefixTable component is defined as an array component of the
2653 LFB. Each row of the array contains an IPv4 address, a Prefix
2654 length, a Hop Selector, an ECMP flag and a Default Route flag. The
2655 LFB uses the destination IPv4 address of every input packet as search
2656 key to look up this table in order extract a next hop selector. The
2657 ECMP flag is for the LFB to support ECMP. The default route flag is
2658 for the LFB to support a default route and for loose RPF.
2660 The IPv4UcastLPMStats component is a struct component which collects
2661 statistics information, including the total number of input packets
2662 received, the IPv4 packets forwarded by this LFB and the number of IP
2663 datagrams discarded due to no route found.Note the component is
2664 defined as optional to implementers.
2666 5.3.1.3. Capabilities
2668 This LFB does not have a list of capabilities
2670 5.3.1.4. Events
2672 This LFB does not have any events specified.
2674 5.3.2. IPv4NextHop
2676 This LFB abstracts the process of selecting ipv4 next hop action.
2678 5.3.2.1. Data Handling
2680 The LFB abstracts the process of next hop information application to
2681 IPv4 packets. It receives an IPv4 packet with an associated next hop
2682 identifier (HopSelector), and uses the identifier as a table index to
2683 look up a next hop table to find an appropriate LFB output port.
2685 The LFB is expected to receive unicast IPv4 packets, via a singleton
2686 input known as "PktsIn" along with a HopSelector metadata which is
2687 used as a table index to lookup the NextHop table. The data
2688 processing involves the forwarding TTL decrement and IP checksum
2689 recalculation.
2691 Two output LFB ports are defined.
2693 The first output is a group output port known as "SuccessOut". On
2694 successful data processing the packet is sent out an LFB-port from
2695 within the LFB port group as selected by the LFBOutputSelectIndex
2696 value of the matched table entry. The packet is sent to a downstream
2697 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
2699 The second output is a singleton output port known as "ExceptionOut",
2700 which will output packets for which the data processing failed, along
2701 with an additional ExceptionID metadata to indicate what caused the
2702 exception. Currently defined exception types include:
2704 o The HopSelector for the packet is invalid.
2706 o The packet failed lookup of the next hop table even though the
2707 HopSelector is valid.
2709 o The MTU for outgoing interface is less than the packet size.
2711 Downstream LFB instances could be either a BasicMetadataDispatch type
2712 (Section 5.5.1), used to fan out to different LFB instances or a
2713 media encapsulation related type, such as an EtherEncap type or a
2714 RedirectOut type(Section 5.4.2). For example, if there are Ethernet
2715 and other tunnel Encapsulation, then a BasicMetadataDispatch LFB can
2716 use the L3PortID metadata (Section 5.3.2.2) to dispatch packets to
2717 different encapsulator.
2719 5.3.2.2. Components
2721 This LFB has only one component named IPv4NextHopTable which is
2722 defined as an array. The HopSelector received is used to match the
2723 array index of IPv4NextHopTable to find out a row of the table as the
2724 next hop information result. Each row of the array is a struct
2725 containing:
2727 o The L3PortID, which is the ID of the Logical Output Port that is
2728 passed onto the downstream LFB instance. This ID indicates what
2729 port to the neighbor is as defined by L3. Usually this ID is used
2730 for the next hop LFB to distinguish packets that need different L2
2731 encapsulating. For instance, some packets may require general
2732 Ethernet encapsulation while others may require various types of
2733 tunnel encapsulations. In such case, different L3PortIDs are
2734 assigned to the packets and are as metadata passed to downstream
2735 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be
2736 applied as the downstream LFB so as to dispatch packets to
2737 different encapsulation LFB instances according to the L3PortIDs.
2739 o MTU, the Maximum Transmission Unit for the outgoing port.
2741 o NextHopIPAddr, the IPv4 next hop address.
2743 o MediaEncapInfoIndex, the index we pass onto the downstream
2744 encapsulation LFB instance and that is used there as a search key
2745 to lookup a table (typically media encapsulation related) for
2746 further encapsulation information. The search key looks up the
2747 table by matching the table index.Note that an encapsulation LFB
2748 instance may not directly follow the next hop LFB, but the index
2749 is passed as a metadata associated, as such an encapsulation LFB
2750 instance even further downstream to the next hop LFB can still use
2751 the index. In some cases, depending on implementation, the CE may
2752 set the MediaEncapInfoIndex passed downstream to a value that will
2753 fail lookup when it gets to a target encapsulation LFB; such a
2754 lookup failure at that point is an indication that further
2755 resolution is needed. For an example of this approach refer to
2756 Section 7.2 which talks about ARP and mentions this approach.
2758 o LFBOutputSelectIndex, the LFB Group output port index to select
2759 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's
2760 table LFBTopology (See [RFC5812]) component FromPortIndex
2761 corresponding to the port group mapping FromLFBID as IPv4NextHop
2762 LFB instance.
2764 5.3.2.3. Capabilities
2766 This LFB does not have a list of capabilities
2768 5.3.2.4. Events
2770 This LFB does not have any events specified.
2772 5.3.3. IPv6UcastLPM
2774 The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match
2775 (LPM) process. The definition of this LFB is similar to the
2776 IPv4UcastLPM LFB except that all IP addresses refer to IPv6
2777 addresses.
2779 This LFB also provides facilities to support users to implement
2780 equal-cost multi-path routing (ECMP) or reverse path forwarding
2781 (RPF). However, this LFB itself does not provide ECMP or RPF. To
2782 fully implement ECMP or RPF, additional specific LFBs, like a
2783 specific ECMP LFB or an RPF LFB, will have to be defined. This work
2784 may be done in the future version of the document.
2786 5.3.3.1. Data Handling
2788 This LFB performs the IPv6 unicast LPM table look up. It always
2789 expects as input IPv6 unicast packets from one singleton input known
2790 as "PktsIn". The destination IPv6 address of an incoming packet is
2791 used as search key to look up the IPv6 prefix table and generate a
2792 hop selector. This hop selector result is associated to the packet
2793 as a metadata and sent to downstream LFBs, and will usually be used
2794 in downstream LFBs as a search key to find more next hop information.
2796 Three singleton output LFB ports are defined.
2798 The first singleton output known as "NormalOut" outputs IPv6 unicast
2799 packets that succeed the LPM lookup (and got a hop selector). The
2800 hop selector is associated with the packet as a metadata. Downstream
2801 from the LPM LFB is usually a next hop application LFB, like an
2802 IPv6NextHop LFB.
2804 The second singleton output known as "ECMPOut" is defined to provide
2805 support for users wishing to implement ECMP.
2807 An ECMP flag is defined in the LPM table to enable the LFB to support
2808 ECMP. When a table entry is created with the flag set true, it
2809 indicates this table entry is for ECMP only. A packet, which has
2810 passed through this prefix lookup, will always output from "ECMPOut"
2811 output port, with the hop selector being its lookup result. The
2812 output will usually directly go to a downstream ECMP processing LFB,
2813 where the hop selector can usually further generate optimized one or
2814 multiple next hop routes by use of ECMP algorithms.
2816 A default route flag is defined in the LPM table to enable the LFB to
2817 support a default route as well as loose RPF. When this flag is set
2818 true, the table entry is identified a default route which also
2819 implies that the route is forbidden for RPF.
2821 If a user wants to implement RPF on FE, a specific RPF LFB will have
2822 to be defined. In such RPF LFB, a component can be defined as an
2823 alias of the prefix table component of this LFB as described below.
2825 The final singleton output is known as "ExceptionOut" and is defined
2826 to allow exception packets to output here, along with an ExceptionID
2827 metadata to indicate what caused the exception. Currently defined
2828 exception types include:
2830 o The packet failed the LPM lookup of the prefix table.
2832 The upstream LFB of this LFB is usually IPv6Validator LFB. If RPF is
2833 to be adopted, the upstream can be an RPF LFB, when defined.
2835 The downstream LFB is usually an IPv6NextHop LFB. If ECMP is
2836 adopted, the downstream can be an ECMP LFB, when defined.
2838 5.3.3.2. Components
2840 This LFB has two components.
2842 The IPv6PrefixTable component is defined as an array component of the
2843 LFB. Each row of the array contains an IPv6 address, a Prefix
2844 length, a Hop Selector, an ECMP flag and a Default Route flag. The
2845 ECMP flag is so the LFB can support ECMP. The default route flag is
2846 for the LFB to support a default route and for loose RPF as described
2847 earlier.
2849 The IPv6UcastLPMStats component is a struct component which collects
2850 statistics information, including the total number of input packets
2851 received, the IPv6 packets forwarded by this LFB and the number of IP
2852 datagrams discarded due to no route found.Note the component is
2853 defined as optional to implementers.
2855 5.3.3.3. Capabilities
2857 This LFB does not have a list of capabilities
2859 5.3.3.4. Events
2861 This LFB does not have any events specified.
2863 5.3.4. IPv6NextHop
2865 This LFB abstracts the process of selecting IPv6 next hop action.
2867 5.3.4.1. Data Handling
2869 The LFB abstracts the process of next hop information application to
2870 IPv6 packets. It receives an IPv6 packet with an associated next hop
2871 identifier (HopSelector), and uses the identifier to look up a next
2872 hop table to find an appropriate output port from the LFB.
2874 The LFB is expected to receive unicast IPv6 packets, via a singleton
2875 input known as "PktsIn" along with a HopSelector metadata which is
2876 used as a table index to lookup the next hop table.
2878 Two output LFB ports are defined.
2880 The first output is a group output port known as "SuccessOut". On
2881 successful data processing the packet is sent out an LFB port from
2882 within the LFB port group as selected by the LFBOutputSelectIndex
2883 value of the matched table entry. The packet is sent to a downstream
2884 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
2886 The second output is a singleton output port known as "ExceptionOut",
2887 which will output packets for which the data processing failed, along
2888 with an additional ExceptionID metadata to indicate what caused the
2889 exception. Currently defined exception types include:
2891 o The HopSelector for the packet is invalid.
2893 o The packet failed lookup of the next hop table even though the
2894 HopSelector is valid.
2896 o The MTU for outgoing interface is less than the packet size.
2898 Downstream LFB instances could be either a BasicMetadataDispatch
2899 type, used to fan out to different LFB instances or a media
2900 encapsulatation related type, such as an EtherEncap type or a
2901 RedirectOut type. For example, when the downstream LFB is
2902 BasicMetadataDispatch, and there exist Ethernet and other tunnel
2903 Encapsulation downstream from BasicMetadataDispatch, then the
2904 BasicMetadataDispatch LFB can use the L3PortID metadata (See section
2905 below) to dispatch packets to the different encapsulator LFBs.
2907 5.3.4.2. Components
2909 This LFB has only one component named IPv6NextHopTable which is
2910 defined as an array. The array index of IPv6NextHopTable is used for
2911 a HopSelector to find out a row of the table as the next hop
2912 information. Each row of the array is a struct containing:
2914 o The L3PortID, which is the ID of the Logical Output Port that is
2915 passed onto the downstream LFB instance. This ID indicates what
2916 port to the neighbor is as defined by L3. Usually this ID is used
2917 for the next hop LFB to distinguish packets that need different L2
2918 encapsulating. For instance, some packets may require general
2919 Ethernet encapsulation while others may require various types of
2920 tunnel encapsulations. In such case, different L3PortIDs are
2921 assigned to the packets and are as metadata passed to downstream
2922 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be
2923 applied as the downstream LFB so as to dispatch packets to
2924 different encapsulation LFB instances according to the L3PortIDs.
2926 o MTU, the Maximum Transmission Unit for the outgoing port.
2928 o NextHopIPAddr, the IPv6 next hop address.
2930 o MediaEncapInfoIndex, the index we pass onto the downstream
2931 encapsulation LFB instance and that is used there as a search key
2932 to lookup a table (typically media encapsulation related) for
2933 further encapsulation information. The saearch key looks up the
2934 table by matching the table index. Note that an encapsulation LFB
2935 instance may not directly follow the next hop LFB, but the index
2936 is passed as a metadata associated, as such an encapsulation LFB
2937 instance even further downstream to the next hop LFB can still use
2938 the index. In some cases, depending on implementation, the CE may
2939 set the MediaEncapInfoIndex passed downstream to a value that will
2940 fail lookup when it gets to a target encapsulation LFB; such a
2941 lookup failure at that point is an indication that further
2942 resolution is needed. For an example of this approach refer to
2943 Section 7.2 which talks about ARP and mentions this approach.
2945 o LFBOutputSelectIndex, the LFB Group output port index to select
2946 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's
2947 table LFBTopology (See [RFC5812]) component FromPortIndex
2948 corresponding to the port group mapping FromLFBID as IPv4NextHop
2949 LFB instance.
2951 5.3.4.3. Capabilities
2953 This LFB does not have a list of capabilities
2955 5.3.4.4. Events
2957 This LFB does not have any events specified.
2959 5.4. Redirect LFBs
2961 Redirect LFBs abstract data packets transportation process between CE
2962 and FE. Some packets output from some LFBs may have to be delivered
2963 to CE for further processing, and some packets generated by CE may
2964 have to be delivered to FE and further to some specific LFBs for data
2965 path processing. According to [RFC5810], data packets and their
2966 associated metadata are encapsulated in ForCES redirect message for
2967 transportation between CE and FE. We define two LFBs to abstract the
2968 process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an LFB
2969 topology of an FE, only one RedirectIn LFB instance and one
2970 RedirectOut LFB instance exist.
2972 5.4.1. RedirectIn
2974 RedirectIn LFB abstracts the process for the CE to inject data
2975 packets into the FE data path.
2977 5.4.1.1. Data Handling
2979 A RedirectIn LFB abstracts the process for the CE to inject data
2980 packets into the FE LFB topology so as to input data packets into FE
2981 data paths. From LFB topology point of view, the RedirectIn LFB acts
2982 as a source point for data packets coming from CE, therefore
2983 RedirectIn LFB is defined with a single output LFB port (and no input
2984 LFB port).
2986 The single output port of RedirectIn LFB is defined as a group output
2987 type, with the name of "PktsOut". Packets produced by this output
2988 will have arbitrary frame types decided by the CE which generated the
2989 packets. Possible frames may include IPv4, IPv6, or ARP protocol
2990 packets. The CE may associate some metadata to indicate the frame
2991 types and may also associate other metadata to indicate various
2992 information on the packets. Among them, there MUST exist a
2993 'RedirectIndex' metadata, which is an integer acting as an index.
2994 When the CE transmits the metadata along with the packet to a
2995 RedirectIn LFB, the LFB will read the RedirectIndex metadata and
2996 output the packet to one of its group output port instance, whose
2997 port index is indicated by this metadata. Any other metadata, in
2998 addition to 'RedirectIndex', will be passed untouched along the
2999 packet delivered by the CE to downstream LFB. This means the
3000 'RedirectIndex' metadata from CE will be "consumed" by the RedirectIn
3001 LFB and will not be passed to downstream LFB. Note that, a packet
3002 from CE without a 'RedirectIndex' metadata associated will be dropped
3003 by the LFB. Note that all metadata visible to the LFB need to be
3004 global and IANA controlled. See the "IANA Considerations" of the
3005 document for more details, where a metadata ID private space that can
3006 be used by vendors is also provided.
3008 5.4.1.2. Components
3010 An optional statistics component is defined to collect the number of
3011 packets received by the LFB from CE. There are no other components
3012 defined for current version of the LFB.
3014 5.4.1.3. Capabilities
3016 This LFB does not have a list of capabilities
3018 5.4.1.4. Events
3020 This LFB does not have any events specified.
3022 5.4.2. RedirectOut
3024 RedirectOut LFB abstracts the process for LFBs in the FE to deliver
3025 data packets to the CE.
3027 5.4.2.1. Data Handling
3029 A RedirectOut LFB abstracts the process for LFBs in the FE to deliver
3030 data packets to the CE. From the LFB's topology point of view, the
3031 RedirectOut LFB acts as a sink point for data packets going to the
3032 CE, therefore RedirectOut LFB is defined with a single input LFB port
3033 (and no output LFB port).
3035 The RedirectOut LFB has only one singleton input known as "PktsIn",
3036 but is capable of receiving packets from multiple LFBs by
3037 multiplexing this input. The input expects any kind of frame type
3038 therefore the frame type has been specified as arbitrary, and also
3039 all types of metadata are expected. All associated metadata produced
3040 (but not consumed) by previous processed LFBs should be delivered to
3041 CE via the ForCES protocol redirect message [RFC5810]. The CE can
3042 decide on how to process the redirected packet by referencing the
3043 associated metadata. As an example, a packet could be redirected by
3044 the FE to the CE because the EtherEncap LFB is not able to resolve L2
3045 information. The metadata "ExceptionID", created by the EtherEncap
3046 LFB is passed along with the packet and should be sufficient for the
3047 CE to do the necessary processing and resolve the L2 entry required.
3048 Note that all metadata visible to the LFB need to be global and IANA
3049 controlled. See the "IANA Considerations" of the document for more
3050 details, where a metadata ID private space that can be used by
3051 vendors is also provided.
3053 5.4.2.2. Components
3055 An optional statistics component is defined to collect the number of
3056 packets sent by the LFB to CE. There are no other components defined
3057 for current version of the LFB.
3059 5.4.2.3. Capabilities
3061 This LFB does not have a list of capabilities
3063 5.4.2.4. Events
3065 This LFB does not have any events specified.
3067 5.5. General Purpose LFBs
3069 5.5.1. BasicMetadataDispatch
3071 The BasicMetadataDispatch LFB is defined to abstract the process in
3072 which a packet is dispatched to some output path based on its
3073 associated metadata value.
3075 5.5.1.1. Data Handling
3077 The BasicMetadataDispatch has only one singleton input known as
3078 "PktsIn". Every input packet should be associated with a metadata
3079 that will be used by the LFB to do the dispatch. This LFB contains a
3080 metadata ID and a dispatch table named MetadataDispatchTable, all
3081 configured by the CE. The metadata ID specifies which metadata is to
3082 be used for dispatching packets. The MetadataDispatchTable contains
3083 entries of a metadata value and an OutputIndex, specifying that the
3084 packet with the metadata value must go out from the LFB group output
3085 port instance with the OutputIndex.
3087 Two output LFB ports are defined.
3089 The first output is a group output port known as "PktsOut". A packet
3090 with its associated metadata having found an OutputIndex by
3091 successfully looking up the dispatch table will be output to the
3092 group port instance with the corresponding index.
3094 The second output is a singleton output port known as "ExceptionOut",
3095 which will output packets for which the data processing failed, along
3096 with an additional ExceptionID metadata to indicate what caused the
3097 exception. Currently defined exception types only include one case:
3099 o There is no matching when looking up the metadata dispatch table.
3101 As an example, if the CE decides to dispatch packets according to a
3102 physical port ID (PHYPortID), the CE may set the ID of PHYPortID
3103 metadata to the LFB first. Moreover, the CE also sets the PHYPortID
3104 actual values (the metadata values) and assigned OutputIndex for the
3105 values to the dispatch table in the LFB. When a packet arrives, a
3106 PHYPortID metadata is found associated with the packet, the metadata
3107 value is further used as a key to look up the dispatch table to find
3108 out an output port instance for the packet.
3110 Currently the BasicMetadataDispatch LFB only allows the metadata
3111 value of the dispatch table entry be 32-bits integer. A metadata
3112 with other types of value is not supported in this version. A more
3113 complex metadata dispatch LFB may be defined in future version of the
3114 library. In that LFB, multiple tuples of metadata with more value
3115 types supported may be used to dispatch packets.
3117 5.5.1.2. Components
3119 This LFB has two components. One component is MetadataID and the
3120 other is MetadataDispatchTable. Each row entry of the dispatch table
3121 is a struct containing metadata value and the OutputIndex. Note that
3122 currently, the metadata value is only allowed to be 32-bits integer.
3124 The metadata value is also defined as a content key for the table.
3125 The concept of content key is a searching key for tables which is
3126 defined in the ForCES FE Model [RFC5812]. With the content key, CE
3127 can manipulate the table by means of a specific metadata value rather
3128 than by the table index only. See [RFC5812] document and also the
3129 ForCES Protocol [RFC5810] for more details on the definition and use
3130 of a content key.
3132 5.5.1.3. Capabilities
3134 This LFB does not have a list of capabilities
3136 5.5.1.4. Events
3138 This LFB does not have any events specified.
3140 5.5.2. GenericScheduler
3142 This is a preliminary generic scheduler LFB for abstracting a simple
3143 scheduling process.
3145 5.5.2.1. Data Handling
3147 There exist various kinds of scheduling strategies with various
3148 implementations. As a base LFB library, this document only defines a
3149 preliminary generic scheduler LFB for abstracting a simple scheduling
3150 process. Users may use this LFB as a basic LFB to further construct
3151 more complex scheduler LFBs by means of "inheritance" as described in
3152 [RFC5812].
3154 Packets of any arbitrary frame type are received via a group input
3155 known as "PktsIn" with no additional metadata expected. This group
3156 input is capable of multiple input port instances. Each port
3157 instance may be connected to different upstream LFB output. Inside
3158 the LFB, it is abstracted that each input port instance is connected
3159 to a queue, and the queue is marked with a queue ID whose value is
3160 exactly the same as the index of corresponding group input port
3161 instance. Scheduling disciplines are applied to all queues and also
3162 all packets in the queues.The group input port property
3163 PortGroupLimits in ObjectLFB as defined by ForCES FE model[RFC5810]
3164 provides means for the CE to query the capability of total queue
3165 numbers the scheduler supports. The CE can then decide how many
3166 queues it may use for a scheduling application.
3168 Scheduled packets are output from a singleton output port of the LFB
3169 knows as "PktsOut" with no corresponding metadata.
3171 More complex scheduler LFBs may be defined with more complex
3172 scheduling disciplines by succeeding this LFB. For instance, a
3173 priority scheduler LFB may be defined by inheriting this LFB and
3174 defining a component to indicate priorities for all input queues.
3176 5.5.2.2. Components
3178 The SchedulingDiscipline component is for the CE to specify a
3179 scheduling discipline to the LFB. Currently defined scheduling
3180 disciplines only include Round Robin (RR) strategy. The default
3181 scheduling discipline is RR then.
3183 The QueueStats component is defined to allow CE to query every queue
3184 status of the scheduler. It is an array component and each row of
3185 the array is a struct containing a queue ID. Currently defined queue
3186 status includes the queue depth in packets and the queue depth in
3187 bytes. Using the queue ID as the index, the CE can query every queue
3188 for its used length in unit of packets or bytes.Note that the
3189 QueueStats componennt is defined as optional to implementers.
3191 5.5.2.3. Capabilities
3193 The following capability is currently defined for the
3194 GenericScheduler.
3196 o The queue length limit providing the storage ability for every
3197 queue.
3199 5.5.2.4. Events
3201 This LFB does not have any events specified.
3203 6. XML for LFB Library
3205
3206
3209
3210
3211
3212 EtherPHYCop
3213
3214 The EtherPHYCop LFB describes an Ethernet interface
3215 which limits the physical media to copper.
3216
3217 1.0
3218
3219
3220 EtherPHYIn
3221
3222 The input port of the EtherPHYCop LFB. It expects any
3223 type of Ethernet frame.
3224
3225
3226
3227 [EthernetAll]
3228
3229
3230
3231
3232
3233
3234 EtherPHYOut
3235
3236 The output port of the EtherPHYCop LFB. The output
3237 packet has the same Ethernet frame type with the
3238 input packet, associated with a metadata indicating
3239 the ID of the physical port.
3240
3241
3242
3243 [EthernetAll]
3244
3245
3246 [PHYPortID]
3247
3248
3249
3251
3252
3253
3254 PHYPortID
3255
3256 The identification of the physical port
3257
3258 uint32
3259
3260
3261 AdminStatus
3262
3263 The port status administratively requested
3264
3265 PortStatusType
3266 2
3267
3268
3269 OperStatus
3270
3271 The port actual operational status
3272
3273 PortStatusType
3274
3275
3276 AdminLinkSpeed
3277
3278 The port link speed administratively requested
3279
3280 LANSpeedType
3281 LAN_SPEED_AUTO
3282
3283
3284 OperLinkSpeed
3285
3286 The port actual operational link speed
3287
3288 LANSpeedType
3289
3290
3291 AdminDuplexMode
3292
3293 The port duplex mode administratively requested
3294
3295 DuplexType
3296 Auto
3297
3298
3299 OperDuplexMode
3300
3301 The port actual operational duplex mode
3302
3303 DuplexType
3304
3305
3306 CarrierStatus
3307 The carrier status of the port
3308 boolean
3309 false
3310
3311
3312
3313
3314 SupportedLinkSpeed
3315
3316 A list of link speeds the port supports
3317
3318
3319 LANSpeedType
3320
3321
3322
3323 SupportedDuplexMode
3324
3325 A list of duplex modes the port supports
3326
3327
3328 DuplexType
3329
3330
3331
3332
3333
3334 PHYPortStatusChanged
3335
3336 An event reporting change on operational status of the
3337 physical port.
3338
3339
3340 OperStatus
3341
3342
3343
3344
3345 OperStatus
3346
3348
3349
3350
3351 LinkSpeedChanged
3352
3353 An event reporting change on operational link speed
3354 of the physical port.
3355
3356
3357 OperLinkSpeed
3358
3359
3360
3361
3362 OperLinkSpeed
3363
3364
3365
3366
3367 DuplexModeChanged
3368
3369 An event reporting change on operational duplex mode
3370 of the physical port.
3371
3372
3373 OperDuplexMode
3374
3375
3376
3377
3378 OperDuplexMode
3379
3380
3381
3382
3383
3384
3385 EtherMACIn
3386
3387 EtherMACIn LFB describes an Ethernet port at MAC data link
3388 layer. The LFB describes Ethernet processing functions
3389 of MAC address locality check, deciding if the Ethernet
3390 packets should be bridged, providing Ethernet layer flow
3391 control, etc.
3392
3393 1.0
3394
3395
3396 EtherPktsIn
3397
3398 The input port of the EtherMACIn LFB. It expects any
3399 type of Ethernet frame.
3400
3401
3402
3403 [EthernetAll]
3404
3405
3406 [PHYPortID]
3407
3408
3409
3410
3411
3412
3413 NormalPathOut
3414
3415 An output port in the EtherMACIn LFB. It outputs
3416 Ethernet packets to downstream LFBs for normal
3417 processing like Ethernet packet classification and
3418 other L3 IP layer processing.
3419
3420
3421
3422 [EthernetAll]
3423
3424
3425 [PHYPortID]
3426
3427
3428
3429
3430 L2BridgingPathOut
3431
3432 An output port in
3433 the EtherMACIn LFB. It outputs Ethernet packets
3434 to downstream LFBs for layer 2 bridging processing.
3435 The port is switched on or off by the
3436 L2BridgingPathEnable flag in the LFB.
3437
3438
3439
3440 [EthernetAll]
3441
3442
3443 [PHYPortID]
3445
3446
3447
3448
3449
3450
3451 AdminStatus
3452
3453 The LFB status administratively requested, which has
3454 the same data type with a port status. Default is in
3455 'down' status.
3456
3457 PortStatusType
3458 2
3459
3460
3461 LocalMACAddresses
3462
3463 Local MAC address(es) of the Ethernet port the LFB
3464 represents.
3465
3466
3467 IEEEMAC
3468
3469
3470
3471 L2BridgingPathEnable
3472
3473 A flag indicating if the LFB L2 BridgingPath output
3474 port is enabled or not. Default is not enabled.
3475
3476 boolean
3477 false
3478
3479
3480 PromiscuousMode
3481
3482 A flag indicating whether the LFB is in promiscuous
3483 mode or not. Default is not.
3484
3485 boolean
3486 false
3487
3488
3489 TxFlowControl
3490
3491 A flag indicating whether transmit flow control is
3492 applied or not. Default is not.
3494
3495
3496 boolean
3497 false
3498
3499
3500 RxFlowControl
3501
3502 A flag indicating whether receive flow control is
3503 applied or not. Default is not.
3504
3505
3506 boolean
3507 false
3508
3509
3510 MACInStats
3511
3512 The statistics of the EtherMACIn LFB
3513
3514
3515 MACInStatsType
3516
3517
3518
3519
3520 EtherClassifier
3521
3522 EtherClassifier LFB describes the process to decapsulate
3523 Ethernet packets and then classify them into various
3524 network layer packets according to information in the
3525 Ethernet headers. It is expected the LFB classifies packets
3526 by packet types like IPv4, IPv6, MPLS, ARP, ND, etc.
3527
3528 1.0
3529
3530
3531 EtherPktsIn
3532
3533 Input port of Ethernet packets. PHYPortID metadata is
3534 always expected while LogicalPortID metadata is
3535 optionally expected to associate with every input
3536 Ethernet packet.
3537
3538
3539
3540 [EthernetAll]
3541
3542
3543 [PHYPortID]
3544 [
3545 LogicalPortID]
3546
3547
3548
3549
3550
3551
3552 ClassifyOut
3553
3554 A group port for output of Ethernet classifying
3555 results.
3556
3557
3558
3559 [Arbitrary]
3560
3561
3562 [PHYPortID]
3563 [SrcMAC]
3564 [DstMAC]
3565 [EtherType]
3566 [VlanID]
3567 [VlanPriority]
3568
3569
3570
3571
3572 ExceptionOut
3573
3574 A singleton port for output of all Ethernet packets
3575 that fail the classifying process. An ExceptionID
3576 metadata indicates the failure reason.
3577
3578
3579
3580 [Arbitrary]
3581
3582
3583 [ExceptionID]
3584
3585
3586
3587
3588
3589
3590 EtherDispatchTable
3591
3592 An EtherDispatchTable array component which is defined
3593 in the LFB to dispatch every Ethernet packet to output
3594 ports according to logical port ID assigned by the
3595 VlanInputTable in the LFB and Ethernet type in the
3596 Ethernet packet header.
3597
3598 EtherDispatchTableType
3599
3600
3601 VlanInputTable
3602
3603 A VlanInputTable array component which is defined in
3604 the LFB to classify VLAN Ethernet packets. Every input
3605 packet is assigned with a new LogicalPortID according
3606 to the packet incoming port ID and VLAN ID.
3607
3608 VlanInputTableType
3609
3610
3611 EtherClassifyStats
3612
3613 A table recording statistics on the Ethernet
3614 classifying process in the LFB.
3615
3616
3617 EtherClassifyStatsTableType
3618
3619
3620
3621
3622 EtherEncap
3623
3624 The EtherEncap LFB abstracts the process of encapsulating
3625 Ethernet headers onto received packets. The encapsulation
3626 is based on passed metadata.
3627
3628 1.0
3629
3630
3631 EncapIn
3632
3633 A input port receiving IPv4 and/or IPv6 packets for
3634 encapsulation. A MediaEncapInfoIndex metadata is
3635 expected and a VLAN priority metadata is optionally
3636 expected with every input packet.
3637
3638
3639
3640 [IPv4]
3641 [IPv6]
3642
3643
3644 [MediaEncapInfoIndex]
3645 [
3646 VlanPriority]
3647
3648
3649
3650
3651
3652
3653 SuccessOut
3654
3655 An output port for packets which have found Ethernet
3656 L2 information and have been successfully encapsulated
3657 into an Ethernet packet. A L2portID metadata is
3658 produced for every output packet.
3659
3660
3661
3662 [IPv4]
3663 [IPv6]
3664
3665
3666 [L2PortID]
3667
3668
3669
3670
3671 ExceptionOut
3672
3673 An output port for packets that fail encapsulation
3674 in the LFB. An ExceptionID metadata indicates failure
3675 reason.
3676
3677
3678
3679 [IPv4]
3680 [IPv6]
3681
3682
3683 [ExceptionID]
3684 [MediaEncapInfoIndex]
3685 [VlanPriority]
3687
3688
3689
3690
3691
3692
3693 EncapTable
3694
3695 An array table for Ethernet encapsulation information
3696 lookup. Each row of the array contains destination MAC
3697 address, source MAC address, VLAN ID, and output
3698 logical L2 port ID.
3699
3700 EncapTableType
3701
3702
3703
3704
3705 EtherMACOut
3706
3707 EtherMACOut LFB abstracts an Ethernet port at MAC data link
3708 layer. It specifically describes Ethernet packet process
3709 for output to physical port. A downstream LFB is usually an
3710 Ethernet physical LFB like EtherPHYcop LFB. Note that
3711 Ethernet output functions are closely related to Ethernet
3712 input functions, therefore some components defined in this
3713 LFB are as alias of EtherMACIn LFB.
3714
3715 1.0
3716
3717
3718 EtherPktsIn
3719
3720 The input port of the EtherMACOut LFB. It expects any
3721 type of Ethernet frame.
3722
3723
3724
3725 [EthernetAll]
3726
3727
3728 [PHYPortID]
3729
3730
3731
3732
3733
3734
3735 EtherPktsOut
3736
3737 A port to output all Ethernet packets, each with a
3738 metadata indicating the physical port ID the packet
3739 is to go.
3740
3741
3742
3743 [EthernetAll]
3744
3745
3746 [PHYPortID]
3747
3748
3749
3750
3751
3752
3753 AdminStatus
3754
3755 The LFB status administratively requested, which has
3756 the same data type with a port status. The component
3757 is defined as alias of AdminStatus component in
3758 EtherMACIn LFB.
3759
3760 PortStatusType
3761
3762
3763 MTU
3764 Maximum transmission unit (MTU)
3765 uint32
3766
3767
3768 TxFlowControl
3769
3770 A flag indicating whether transmit flow control is
3771 applied, defined as alias of TxFlowControl component
3772 in EtherMACIn LFB.
3773
3774
3775 boolean
3776
3777
3778 RxFlowControl
3779
3780 A flag indicating whether receive flow control is
3781 applied, defined as alias of RxFlowControl component
3782 in EtherMACIn LFB.
3784
3785
3786 boolean
3787
3788
3789 MACOutStats
3790
3791 The statistics of the EtherMACOut LFB
3792
3793
3794 MACOutStatsType
3795
3796
3797
3798
3799 IPv4Validator
3800
3801 This LFB performs IPv4 validation according to RFC1812 and
3802 its updates. The IPv4 packet will be output to the
3803 corresponding LFB port, indicating whether the packet is
3804 unicast, multicast or whether an exception has occurred or
3805 the validation failed.
3806
3807 1.0
3808
3809
3810 ValidatePktsIn
3811
3812 Input port for data packets to be validated
3813
3814
3815
3816 [Arbitrary]
3817
3818
3819
3820
3821
3822
3823 IPv4UnicastOut
3824
3825 Output port for validated IPv4 unicast packets
3826
3827
3828
3829 [IPv4Unicast]
3830
3831
3833
3834
3835 IPv4MulticastOut
3836
3837 Output port for validated IPv4 multicast packets
3838
3839
3840
3841 [IPv4Multicast]
3842
3843
3844
3845
3846 ExceptionOut
3847
3848 Output port for all packets with exceptional cases
3849 when validating. An ExceptionID metadata indicates
3850 the exception case type.
3851
3852
3853
3854 [IPv4]
3855
3856
3857 [ExceptionID]
3858
3859
3860
3861
3862 FailOut
3863
3864 Output port for packets failed validating process.
3865 A ValidateErrorID metadata indicates the error type
3866 or failure reason.
3867
3868
3869
3870 [IPv4]
3871
3872
3873 [ValidateErrorID]
3874
3875
3876
3877
3878
3879
3880 IPv4ValidatorStats
3881
3882 The statistics information for validating process in
3883 the LFB.
3884
3885
3886 IPv4ValidatorStatsType
3887
3888
3889
3890
3891 IPv6Validator
3892
3893 This LFB performs IPv6 validation according to RFC2460 and
3894 its updates. Then the IPv6 packet will be output to the
3895 corresponding port, indicating whether the packet is a
3896 unicast or a multicast one, an exception has occurred or
3897 the validation failed.
3898
3899 1.0
3900
3901
3902 ValidatePktsIn
3903
3904 Input port for data packets to be validated
3905
3906
3907
3908 [Arbitrary]
3909
3910
3911
3912
3913
3914
3915 IPv6UnicastOut
3916
3917 Output port for validated IPv6 unicast packets
3918
3919
3920
3921 [IPv6Unicast]
3922
3923
3924
3925
3926 IPv6MulticastOut
3927
3928 Output port for validated IPv6 multicast packets
3930
3931
3932
3933 [IPv6Multicast]
3934
3935
3936
3937
3938 ExceptionOut
3939
3940 Output port for packets with exceptional cases when
3941 validating. An ExceptionID metadata indicates the
3942 exception case type.
3943
3944
3945
3946 [IPv6]
3947
3948
3949 [ExceptionID]
3950
3951
3952
3953
3954 FailOut
3955
3956 Output port for packets failed validating process.
3957 A ValidateErrorID metadata indicates the error type
3958 or failure reason.
3959
3960
3961
3962 [IPv6]
3963
3964
3965 [ValidateErrorID]
3966
3967
3968
3969
3970
3971
3972 IPv6ValidatorStats
3973
3974 The statistics information for validating process in
3975 the LFB.
3976
3977
3978 IPv6ValidatorStatsType
3979
3980
3981
3982
3983 IPv4UcastLPM
3984
3985 The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest
3986 Prefix Match (LPM) process. This LFB supports to implement
3987 equal-cost multi-path routing (ECMP) and reverse path
3988 forwarding (RPF).
3989
3990 1.0
3991
3992
3993 PktsIn
3994
3995 A port for input of packets to be processed. IPv4
3996 unicast packets are expected.
3997
3998
3999
4000 [IPv4Unicast]
4001
4002
4003
4004
4005
4006
4007 NormalOut
4008
4009 An output port to output IPv4 unicast packets
4010 successfully passed the LPM lookup. A HopSelector
4011 metadata is produced to associate every output packet
4012 for downstream LFB to do next hop action.
4013
4014
4015
4016 [IPv4Unicast]
4017
4018
4019 [HopSelector]
4020
4021
4022
4023
4024 ECMPOut
4025
4026 The port to output packets needing further ECMP
4027 processing. A downstream ECMP processing LFB is usually
4028 followed to the port. If ECMP is not required, no
4029 downstream LFB may be connected to the port.
4030
4031
4032
4033 [IPv4Unicast]
4034
4035
4036 [HopSelector]
4037
4038
4039
4040
4041 ExceptionOut
4042
4043 The port to output all packets with exceptional cases
4044 happened during LPM process. An ExceptionID metadata
4045 is associated to indicate what caused the exception.
4046
4047
4048
4049 [IPv4Unicast]
4050
4051
4052 [ExceptionID]
4053
4054
4055
4056
4057
4058
4059 IPv4PrefixTable
4060
4061 A table for IPv4 Longest Prefix Match(LPM). The
4062 destination IPv4 address of every input packet is
4063 used as a search key to look up the table to find
4064 out a next hop selector.
4065
4066 IPv4PrefixTableType
4067
4068
4069 IPv4UcastLPMStats
4070
4071 The statistics information for the IPv4 unicast LPM
4072 process in the LFB.
4073
4074
4075 IPv4UcastLPMStatsType
4076
4077
4078
4079
4080 IPv6UcastLPM
4081
4082 The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest
4083 Prefix Match (LPM) process. This LFB supports to implement
4084 equal-cost multi-path routing (ECMP) and reverse path
4085 forwarding (RPF).
4086
4087 1.0
4088
4089
4090 PktsIn
4091
4092 A port for input of packets to be processed. IPv6
4093 unicast packets are expected.
4094
4095
4096
4097 [IPv6Unicast]
4098
4099
4100
4101
4102
4103
4104 NormalOut
4105
4106 An output port to output IPv6 unicast packets
4107 successfully passed the LPM lookup. A HopSelector
4108 metadata is produced to associate every output packet
4109 for downstream LFB to do next hop action.
4110
4111
4112
4113 [IPv6Unicast]
4114
4115
4116 [HopSelector]
4117
4118
4119
4120
4121 ECMPOut
4122
4123 The port to output packets needing further ECMP
4124 processing. A downstream ECMP processing LFB is usually
4125 followed to the port. If ECMP is not required, no
4126 downstream LFB may be connected to the port.
4127
4128
4129
4130 [IPv6Unicast]
4131
4132
4133 [HopSelector]
4134
4135
4136
4137
4138 ExceptionOut
4139
4140 The port to output all packets with exceptional cases
4141 happened during LPM process. An ExceptionID metadata
4142 is associated to indicate what caused the exception.
4143
4144
4145
4146 [IPv6Unicast]
4147
4148
4149 [ExceptionID]
4150
4151
4152
4153
4154
4155
4156 IPv6PrefixTable
4157
4158 A table for IPv6 Longest Prefix Match(LPM). The
4159 destination IPv6 address of every input packet is
4160 used as a search key to look up the table to find
4161 out a next hop selector.
4162
4163 IPv6PrefixTableType
4164
4165
4166 IPv6UcastLPMStats
4167
4168 The statistics information for the IPv6 unicast LPM
4169 process in the LFB.
4171
4172
4173 IPv6UcastLPMStatsType
4174
4175
4176
4177
4178 IPv4NextHop
4179
4180 The IPv4NextHop LFB abstracts the process of next hop
4181 information application to IPv4 packets. It receives an IPv4
4182 packet with an associated next hop identifier (HopSelector),
4183 uses the identifier as a table index to look up a next hop
4184 table to find an appropriate output port. The data
4185 processing also involves the forwarding TTL decrement and
4186 IP checksum recalculation.
4187
4188 1.0
4189
4190
4191 PktsIn
4192
4193 A port for input of unicast IPv4 packets, along with
4194 a HopSelector metadata.
4195
4196
4197
4198 [IPv4Unicast]
4199
4200
4201 [HopSelector]
4202
4203
4204
4205
4206
4207
4208 SuccessOut
4209
4210 The group port for output of packets who successfully
4211 found next hop information. Some metadata are
4212 associated with every packet.
4213
4214
4215
4216 [IPv4Unicast]
4217
4218
4219 [L3PortID]
4220 [NextHopIPv4Addr]
4221 [
4222 MediaEncapInfoIndex]
4223
4224
4225
4226
4227 ExceptionOut
4228
4229 The output port for packets with exceptional or
4230 failure case. An ExceptionID metadata indicates what
4231 caused the case.
4232
4233
4234
4235 [IPv4Unicast]
4236
4237
4238 [ExceptionID]
4239
4240
4241
4242
4243
4244
4245 IPv4NextHopTable
4246
4247 The IPv4NextHopTable component. A
4248 HopSelector is used to match the table index
4249 to find out a row which contains the next hop
4250 information result.
4251
4252 IPv4NextHopTableType
4253
4254
4255
4256
4257 IPv6NextHop
4258
4259 The LFB abstracts the process of next hop information
4260 application to IPv6 packets. It receives an IPv6 packet
4261 with an associated next hop identifier (HopSelector),
4262 uses the identifier as a table index to look up a next hop
4263 table to find an appropriate output port.
4264
4265 1.0
4266
4267
4268 PktsIn
4269
4270 A port for input of unicast IPv6 packets, along with
4271 a HopSelector metadata.
4272
4273
4274
4275 [IPv6Unicast]
4276
4277
4278 [HopSelector]
4279
4280
4281
4282
4283
4284
4285 SuccessOut
4286
4287 The group port for output of packets who successfully
4288 found next hop information. Some metadata are
4289 associated with every packet.
4290
4291
4292
4293 [IPv6Unicast]
4294
4295
4296 [L3PortID]
4297 [NextHopIPv6Addr]
4298 [
4299 MediaEncapInfoIndex]
4300
4301
4302
4303
4304 ExceptionOut
4305
4306 The output port for packets with exceptional or
4307 failure case. An ExceptionID metadata indicates what
4308 caused the case.
4309
4310
4311
4312 [IPv6Unicast]
4313
4314
4315 [ExceptionID]
4316
4317
4318
4319
4320
4321
4322 IPv6NextHopTable
4323
4324 The IPv6NextHopTable component. A HopSelector is used
4325 to match the table index to find out a row which
4326 contains the next hop information result.
4327
4328 IPv6NextHopTableType
4329
4330
4331
4332
4333 RedirectIn
4334
4335 The RedirectIn LFB abstracts the process for the ForCES CE to
4336 inject data packets into the ForCES FE LFBs.
4337
4338 1.0
4339
4340
4341 PktsOut
4342
4343 The output port of RedirectIn LFB, which is defined as
4344 a group port type. From LFB topology point of view,
4345 the RedirectIn LFB acts as a source point for data
4346 packets coming from CE, therefore the LFB is
4347 defined with a singleton output port (and no input
4348 port).
4349
4350
4351
4352 [Arbitrary]
4353
4354
4355
4356
4357
4358
4359 NumPacketsReceived
4360
4361 Number of packets received from CE.
4362
4363
4364 uint64
4365
4366
4367
4368
4369 RedirectOut
4370
4371 The RedirectOut LFB abstracts the process for LFBs in a
4372 ForCES FE to deliver data packets to the ForCES CE.
4373
4374 1.0
4375
4376
4377 PktsIn
4378
4379 The input port for the RedirectOut LFB. From the LFB's
4380 topology point of view, the RedirectOut LFB acts as a
4381 sink point for data packets going to the CE, therefore
4382 RedirectOut LFB is defined with a singleton input
4383 port (and no output port).
4384
4385
4386
4387 [Arbitrary]
4388
4389
4390
4391
4392
4393
4394 NumPacketsSent
4395
4396 Numble of packets sent to CE.
4397
4398
4399 uint64
4400
4401
4402
4403
4404 BasicMetadataDispatch
4405
4406 The BasicMetadataDispatch LFB is defined to abstract the
4407 process by which packets are dispatched to various output
4408 paths based on associated metadata value. Current version of
4409 the LFB only allows the metadata value be 32-bits integer.
4410
4411 1.0
4412
4413
4414 PktsIn
4415
4416 The packet input port for dispatching. Every input
4417 packet should be associated with a metadata that will
4418 be used by the LFB to do the dispatch.
4419
4420
4421
4422 [Arbitrary]
4423
4424
4425 [Arbitrary]
4426
4427
4428
4429
4430
4431
4432 PktsOut
4433
4434 The group output port which outputs dispatching
4435 results. A packet with its associated metadata having
4436 found an OutputIndex by successfully looking up the
4437 dispatch table will be output to the group port
4438 instance with the corresponding index.
4439
4440
4441
4442 [Arbitrary]
4443
4444
4445
4446
4447 ExceptionOut
4448
4449 The output port which outputs packets which failed
4450 to process. An ExceptionID metadata indicates what
4451 caused the exception.
4452
4453
4454
4455 [Arbitrary]
4456
4457
4458 [ExceptionID]
4460
4461
4462
4463
4464
4465
4466 MetadataID
4467
4468 The ID of the metadata to be
4469 used for dispatching packets.
4470
4471 uint32
4472
4473
4474 MetadataDispatchTable
4475
4476 The MetadataDispatchTable component, which contains
4477 entries of a metadata value and an output index,
4478 specifying that a packet with the metadata value must
4479 go out from the instance with the output index of the
4480 LFB group output port.
4481
4482 MetadataDispatchTableType
4483
4484
4485
4486
4487 GenericScheduler
4488
4489 This is a preliminary generic scheduler LFB abstracting
4490 a simple scheduling process, which may be used as a
4491 basic LFB to construct a more complex scheduler LFB.
4492
4493 1.0
4494
4495
4496 PktsIn
4497
4498 The group input port of the LFB. Inside the LFB,
4499 each instance of the group port is connected to
4500 a queue marked with a queue ID, whose value is
4501 index of the port instance.
4502
4503
4504
4505 [Arbitrary]
4506
4507
4509
4510
4511
4512
4513 PktsOut
4514
4515 The output port of the LFB. Scheduled packets are
4516 output from the port.
4517
4518
4519
4520 [Arbitrary]
4521
4522
4523
4524
4525
4526
4527 SchedulingDiscipline
4528
4529 The SchedulingDiscipline component, which is for the
4530 CE to specify a scheduling discipline to the LFB.
4531
4532 SchdDisciplineType
4533 1
4534
4535
4536 QueueStats
4537
4538 The QueueStats component, which is defined to allow
4539 CE to query every queue statistics in the scheduler.
4540
4541
4542 QueueStatsTableType
4543
4544
4545
4546
4547 QueueLenLimit
4548
4549 The QueueLenLimit capability, which specifies
4550 maximum length of each queue. The length unit is in
4551 bytes.
4552
4553 uint32
4554
4555
4556
4558
4559
4560 7. LFB Class Use Cases
4562 This section demonstrates examples on how the LFB classes defined by
4563 the Base LFB library in Section 6 can be applied to achieve some
4564 typical router functions. The functions demonstrated are:
4566 o IPv4 forwarding
4568 o ARP processing
4570 It is assumed the LFB topology on the FE described has already been
4571 established by the CE and maps to the use cases illustrated in this
4572 section.
4574 The use cases demonstrated in this section are mere examples and by
4575 no means should be treated as the only way one would construct router
4576 functionality from LFBs; based on the capability of the FE(s), a CE
4577 should be able to express different NE applications.
4579 7.1. IPv4 Forwarding
4581 Figure 2 shows the typical LFB processing path for an IPv4 unicast
4582 forwarding case with Ethernet media interfaces by use of the base LFB
4583 classes. Note that in the figure, to focus on the IP forwarding
4584 function, some inputs or outputs of LFBs that are not related to the
4585 IPv4 forwarding function are not shown. For example, an
4586 EtherClassifier LFB normally has two output ports: a "ClassifyOut"
4587 group output port and a "ExceptionOut" singleton output port, with
4588 the group port contains various port instances according to various
4589 classified packet types(Section 5.1.3). While in this figure, only
4590 the IPv4 and IPv6 packet output port instances are shown for
4591 displaying the mere IPv4 forwarding processing function.
4593 +-----+ +------+
4594 | | | |
4595 | |<---------------|Ether |<----------------------------+
4596 | | |MACOut| |
4597 | | | | |
4598 |Ether| +------+ |
4599 |PHY | |
4600 |Cop | +---+ |
4601 |#1 | +-----+ | |----->IPv6 Packets |
4602 | | | | | | |
4603 | | |Ether| | | IPv4 Packets |
4604 | |->|MACIn|-->| |-+ +----+ |
4605 +-----+ | | | | | | |---> Multicast Packets |
4606 +-----+ +---+ | | | +-----+ +---+ |
4607 Ether +->| |------->| | | | |
4608 . Classifier| | |Unicast |IPv4 | | | |
4609 . | | |Packets |Ucast|->| |--+ |
4610 . | +----+ |LPM | | | | |
4611 +---+ | IPv4 +-----+ +---+ | |
4612 +-----+ | | | Validator IPv4 | |
4613 | | | | | NextHop| |
4614 +-----+ |Ether| | |-+ IPv4 Packets | |
4615 | |->|MACIn|-->| | | |
4616 | | | | | |----->IPv6 Packets | |
4617 |Ether| +-----+ +---+ | |
4618 |PHY | Ether +----+ | |
4619 |Cop | Classifier | | +-------+ | |
4620 |#n | +------+ | | |Ether | | |
4621 | | | | | |<--|Encap |<-+ |
4622 | | | |<------| | | | |
4623 | |<---------------|Ether | ...| | +-------+ |
4624 | | |MACOut| +---| | |
4625 | | | | | +----+ |
4626 +-----+ +------+ | BasicMetadataDispatch |
4627 +----------->-------------+
4629 Figure 2: LFB use case for IPv4 forwarding
4631 In the LFB use case, a number of EtherPHYCop LFB(Section 5.1.1)
4632 instances are used to describe physical layer functions of the ports.
4633 PHYPortID metadata is generated by EtherPHYCop LFB and is used by all
4634 the subsequent downstream LFBs. An EtherMACIn LFB(Section 5.1.2),
4635 which describe the MAC layer processing, follows every EtherPHYCop
4636 LFB. The EtherMACIn LFB may do a locality check of MAC addresses if
4637 the CE configures the appropriate EtherMACIn LFB component.
4639 Ethernet packets out of the EtherMACIn LFB are sent to an
4640 EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified
4641 into network layer types like IPv4, IPv6, ARP, etc. In the example
4642 use case, every physical Ethernet interface is associated with one
4643 Classifier instance; although not illustrated, it is also feasible
4644 that all physical interfaces are associated with only one Ethernet
4645 Classifier instance.
4647 EtherClassifier uses the PHYPortID metadata, the Ethernet type of the
4648 input packet, and VlanID (if present in the input Ethernet packets),
4649 to decide the packet network layer type and the LFB output port to
4650 the downstream LFB. The EtherClassifier LFB also assigns a new
4651 logical port ID metadata to the packet for later use. The
4652 EtherClassifier may also generate some new metadata for every packet
4653 like EtherType, SrcMAC, DstMAC, LogicPortID, etc for consumption by
4654 downstream LFBs.
4656 If a packet is classified as an IPv4 packet, it is sent downstream to
4657 an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet. In
4658 the validator LFB, IPv4 packets are validated and are additionally
4659 classified into either IPv4 unicast packets or multicast packets.
4660 IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB
4661 (Section 5.3.1).
4663 The IPv4UcastLPM LFB is where the longest prefix match decision is
4664 made, and a next hop selection is selected. The next hop ID metadata
4665 is generated by the IPv4UcastLPM LFB to be consumed downstream by the
4666 IPv4NextHop LFB (Section 5.3.2).
4668 The IPv4NextHop LFB uses the next hop ID metadata to do derive where
4669 the packet is to go next and the media encapsulation type for the
4670 port, etc. The IPv4NextHop LFB generates the L3PortID metadata used
4671 to identify a next hop output physical/logical port. In the example
4672 use case, the next hop output port is an Ethernet type; as a result,
4673 the packet and its L3 port ID metadata are sent downstream to an
4674 EtherEncap LFB (Section 5.1.4).
4676 The EtherEncap LFB encapsulates the incoming packet into an Ethernet
4677 frame. A BasicMetadataDispatch LFB (Section 5.5.1) follows the
4678 EtherEncap LFB. The BasicMetadataDispatch LFB is where packets are
4679 finally dispatched to different output physical/logical ports based
4680 on the L3PortID metadata sent to the LFB.
4682 7.2. ARP processing
4684 Figure 3 shows the processing path for ARP protocol in the case the
4685 CE implements the ARP processing function. By no means is this the
4686 only way ARP processing could be achieved; as an example ARP
4687 processing could happen at the FE - but that discussion is out of
4688 scope for this use case.
4690 +---+ +---+
4691 | | ARP packets | |
4692 | |-------------->---------+--->| | To CE
4693 ...-->| | . | | |
4694 | | . | +---+
4695 | | . | RedirectOut
4696 +---+ ^
4697 Ether EtherEncap | IPv4 packets lack
4698 Classifier +---+ | address resolution information
4699 | | |
4700 Packets need | |--------->---+
4701 ...--------->| |
4702 L2 Encapsulation| |
4703 +---+ | | +------+
4704 | | +-->| |--+ +---+ |Ether |
4705 | | | +---+ | | |--------->|MACOut|-->...
4706 From CE| |--+ +-->| | . +------+
4707 | |ARP Packets | | .
4708 | |from CE | | . +------+
4709 | | | |--------> |Ether |-->...
4710 +---+ +---+ |MACOut|
4711 RedirectIn BasicMetadata +------+
4712 Dispatch
4714 Figure 3: LFB use case for ARP
4716 There are two ways ARP processing could be triggered in the CE as
4717 illustrated in Figure 3:
4719 o ARP packets arriving from outside of the NE.
4721 o IPV4 packets failing to resolve within the FE.
4723 ARP packets from network interfaces are filtered out by
4724 EtherClassifier LFB. The classified ARP packets and associated
4725 metadata are then sent downstream to the RedirectOut LFB
4726 (Section 5.4.2) to be transported to CE.
4728 The EtherEncap LFB, as described in Section 5.1.4, receives packets
4729 that need Ethernet L2 encapsulating. When the EtherEncap LFB fails
4730 to find the necessary L2 Ethernet information to encapsulate the
4731 packet with, it outputs the packet to its ExceptionOut LFB port.
4732 Downstream to EtherEncap LFB's ExceptionOut LFB port is the
4733 RedirectOut LFB which transports the packet to the CE (Section 5.1.4
4734 on EtherEncap LFB for details).
4736 To achieve its goal, the CE needs to generate ARP request and
4737 response packets and send them to external (to the NE) networks. ARP
4738 request and response packets from the CE are redirected to an FE via
4739 a RedirectIn LFB (Section 5.4.1).
4741 As was the case with forwarded IPv4 packets, outgoing ARP packets are
4742 also encapsulated to Ethernet format by the EtherEncap LFB, and then
4743 dispatched to different interfaces via a BasicMetadataDispatch LFB.
4744 The BasicMetadataDispatch LFB dispatches the packets according to the
4745 L3PortID metadata included in every ARP packet sent from CE.
4747 8. Contributors
4749 The authors would like to thank Jamal Hadi Salim, Ligang Dong, and
4750 Fenggen Jia who made major contributions to the development of this
4751 document. Ligang Dong and Fenggen Jia were also two of the authors
4752 of earlier documents which this document is evolved from.
4754 Jamal Hadi Salim
4755 Mojatatu Networks
4756 Ottawa, Ontario
4757 Canada
4758 Email: hadi@mojatatu.com
4760 Ligang Dong
4761 Zhejiang Gongshang University
4762 18 Xuezheng Str., Xiasha University Town
4763 Hangzhou,310018
4764 P.R.China
4765 EMail: donglg@zjsu.edu.cn
4767 Fenggen Jia
4768 National Digital Switching Center(NDSC)
4769 Jianxue Road
4770 Zhengzhou 452000
4771 P.R.China
4772 EMail: jfg@mail.ndsc.com.cn
4774 9. Acknowledgements
4776 The authors would like to acknowledge the following people, whose
4777 input has been particularly helpful during development of this
4778 document:
4780 Edward Crabbe
4781 Adrian Farrel
4782 Rong Jin
4783 Bin Zhuge
4784 Ming Gao
4785 Jingjing Zhou
4786 Xiaochun Wu
4787 Derek Atkins
4788 Stephen Farrel
4789 Meral Shirazipour
4790 Jari Arkko
4791 Martin Stiemerling
4792 Stewart Bryant
4793 Richard Barnes
4795 10. IANA Considerations
4797 IANA has created a registry of ForCES LFB Class Names and the
4798 corresponding ForCES LFB Class Identifiers, with the location of the
4799 definition of the ForCES LFB Class, in accordance with the rules to
4800 use the namespace.
4802 The LFB library in this document needs for unique class names and
4803 numeric class identifiers of all LFBs. Besides, this document also
4804 needs to define the following namespaces:
4806 o Metadata ID, defined in Section 4.3 and Section 4.4
4808 o Exception ID, defined in Section 4.4
4810 o Validate Error ID, defined in Section 4.4
4812 10.1. LFB Class Names and LFB Class Identifiers
4814 LFB classes defined by this document belongs to IETF defined LFBs by
4815 Standard Track RFCs. According to IANA, the identifier namespace for
4816 these LFB classes is from 3 to 65535.
4818 The assignment of LFB class names and LFB class identifiers is as in
4819 the following table.
4821 +-----------+---------------+------------------------+--------------+
4822 | LFB Class | LFB Class Name| Description | Reference |
4823 | Identifier| | | |
4824 +-----------+---------------+------------------------+--------------+
4825 | 3 | EtherPHYCop | Define an Ethernet port| RFC????(this|
4826 | | | abstracted at physical | document) |
4827 | | | layer. | Section 5.1.1|
4828 | | | | |
4829 | 4 | EtherMACIn | Define an Ethernet | RFC???? |
4830 | | | input port at MAC data | Section 5.1.2|
4831 | | | link layer. | |
4832 | | | | |
4833 | 5 |EtherClassifier| Define the process to | RFC???? |
4834 | | | decapsulate Ethernet | Section 5.1.3|
4835 | | | packets and classify | |
4836 | | | the packets. | |
4837 | | | | |
4838 | 6 | EtherEncap | Define the process to | RFC???? |
4839 | | | encapsulate IP packets | Section 5.1.4|
4840 | | | to Ethernet packets. | |
4841 | | | | |
4842 | 7 | EtherMACOut | Define an Ethernet | RFC ???? |
4843 | | | output port at MAC | Section 5.1.5|
4844 | | | data link layer. | |
4845 | | | | |
4846 | 8 | IPv4Validator | Perform IPv4 packets | RFC ???? |
4847 | | | validation. | Section 5.2.1|
4848 | | | | |
4849 | 9 | IPv6Validator | Perform IPv6 packets | RFC ???? |
4850 | | | validation. | Section 5.2.2|
4851 | | | | |
4852 | 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? |
4853 | | | Prefix Match Lookup. | Section 5.3.1|
4854 | | | | |
4855 | 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? |
4856 | | | Prefix Match Lookup. | Section 5.3.3|
4857 | | | | |
4858 | 12 | IPv4NextHop | Define the process of | RFC ??? |
4859 | | | selecting Ipv4 next hop| Section 5.3.2|
4860 | | | action. | |
4861 | | | | |
4862 | 13 | IPv6NextHop | Define the process of | RFC ??? |
4863 | | | selecting Ipv6 next hop| Section 5.3.4|
4864 | | | action. | |
4865 | | | | |
4866 | 14 | RedirectIn | Define the process for | RFC ??? |
4867 | | | CE to inject data | Section 5.4.1|
4868 | | | packets into FE LFB | |
4869 | | | topology. | |
4870 | | | | |
4871 | 15 | RedirectOut | Define the process for | RFC ??? |
4872 | | | LFBs in FE to deliver | Section 5.4.2|
4873 | | | data packets to CE. | |
4874 | | | | |
4875 | 16 | BasicMetadata | Dispatch input packets | RFC ??? |
4876 | | Dispatch | to a group output | Section 5.5.1|
4877 | | | according to a metadata| |
4878 | | | | |
4879 | 17 | Generic | Define a preliminary | RFC ???? |
4880 | | Scheduler | generic scheduling | Section 5.5.2|
4881 | | | process. | |
4882 +-----------+---------------+------------------------+--------------+
4884 Table 1
4886 10.2. Metadata ID
4888 The Metadata ID namespace is 32 bits long. The following is the
4889 guideline for managing the namespace.
4891 Metadata ID 0x00000000-0x7FFFFFFF
4892 Metadata with IDs in this range are Specification Required
4893 [RFC5226]. A metadata ID using this range MUST be documented in
4894 an RFC or other permanent and readily available references.
4896 Values assigned by this specification:
4898 +--------------+-------------------------+--------------------------+
4899 | Value | Name | Definition |
4900 +--------------+-------------------------+--------------------------+
4901 | 0x00000001 | PHYPortID | See Section 4.4 |
4902 | 0x00000002 | SrcMAC | See Section 4.4 |
4903 | 0x00000003 | DstMAC | See Section 4.4 |
4904 | 0x00000004 | LogicalPortID | See Section 4.4 |
4905 | 0x00000005 | EtherType | See Section 4.4 |
4906 | 0x00000006 | VlanID | See Section 4.4 |
4907 | 0x00000007 | VlanPriority | See Section 4.4 |
4908 | 0x00000008 | NextHopIPv4Addr | See Section 4.4 |
4909 | 0x00000009 | NextHopIPv6Addr | See Section 4.4 |
4910 | 0x0000000A | HopSelector | See Section 4.4 |
4911 | 0x0000000B | ExceptionID | See Section 4.4 |
4912 | 0x0000000C | ValidateErrorID | See Section 4.4 |
4913 | 0x0000000D | L3PortID | See Section 4.4 |
4914 | 0x0000000E | RedirectIndex | See Section 4.4 |
4915 | 0x0000000F | MediaEncapInfoIndex | See Section 4.4 |
4916 +--------------+-------------------------+--------------------------+
4918 Table 2
4920 Metadata ID 0x80000000-0xFFFFFFFF
4921 Metadata IDs in this range are reserved for vendor private
4922 extensions and are the responsibility of individuals, i.e., used
4923 according to the Private Use [RFC5226] policy.
4925 10.3. Exception ID
4927 The Exception ID namespace is 32 bits long. The following is the
4928 guideline for managing the namespace.
4930 Exception ID 0x00000000-0x7FFFFFFF
4931 Exception IDs in this range are Specification Required [RFC5226].
4932 An exception ID using this range MUST be documented in an RFC or
4933 other permanent and readily available references.
4935 Values assigned by this specification:
4937 +--------------+---------------------------------+------------------+
4938 | Value | Name | Definition |
4939 +--------------+---------------------------------+------------------+
4940 | 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 |
4941 | 0x00000001 | ClassifyNoMatching | See Section 4.4 |
4942 | 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 |
4943 | 0x00000003 | EncapTableLookupFailed | See Section 4.4 |
4944 | 0x00000004 | BadTTL | See Section 4.4 |
4945 | 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 |
4946 | 0x00000006 | RouterAlertOptions | See Section 4.4 |
4947 | 0x00000007 | IPv6HopLimitZero | See Section 4.4 |
4948 | 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 |
4949 | 0x00000009 | SrcAddressExecption | See Section 4.4 |
4950 | 0x0000000A | DstAddressExecption | See Section 4.4 |
4951 | 0x0000000B | LPMLookupFailed | See Section 4.4 |
4952 | 0x0000000C | HopSelectorInvalid | See Section 4.4 |
4953 | 0x0000000D | NextHopLookupFailed | See Section 4.4 |
4954 | 0x0000000E | FragRequired | See Section 4.4 |
4955 | 0x0000000F | MetadataNoMatching | See Section 4.4 |
4956 +--------------+---------------------------------+------------------+
4958 Table 3
4960 Exception ID 0x80000000-0xFFFFFFFF
4961 Exception IDs in this range are reserved for vendor private
4962 extensions and are the responsibility of individuals, i.e., used
4963 according to the Private Use [RFC5226] policy.
4965 10.4. Validate Error ID
4967 The Validate Error ID namespace is 32 bits long. The following is
4968 the guideline for managing the namespace.
4970 Validate Error ID 0x00000000-0x7FFFFFFF
4971 Validate Error IDs in this range are Specification Required
4972 [RFC5226]. A Validate Error ID using this range MUST be
4973 documented in an RFC or other permanent and readily available
4974 references.
4976 Values assigned by this specification:
4978 +--------------+---------------------------------+------------------+
4979 | Value | Name | Definition |
4980 +--------------+---------------------------------+------------------+
4981 | 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 |
4982 | 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 |
4983 | 0x00000002 | NotIPv4Packet | See Section 4.4 |
4984 | 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 |
4985 | 0x00000004 | InvalidIPv4LengthFieldSize | See Section 4.4 |
4986 | 0x00000005 | InvalidIPv4Checksum | See Section 4.4 |
4987 | 0x00000006 | InvalidIPv4SrcAddr | See Section 4.4 |
4988 | 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 |
4989 | 0x00000008 | InvalidIPv6PakcetSize | See Section 4.4 |
4990 | 0x00000009 | NotIPv6Packet | See Section 4.4 |
4991 | 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 |
4992 | 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 |
4993 +--------------+---------------------------------+------------------+
4994 Table 4
4996 Validate Error ID 0x80000000-0xFFFFFFFF
4997 Validate Error IDs in this range are reserved for vendor private
4998 extensions and are the responsibility of individuals, i.e., used
4999 according to the Private Use [RFC5226] policy.
5001 11. Security Considerations
5003 The ForCES framework document [RFC3746] provides a description of the
5004 security needs for the overall ForCES architecture. For example, the
5005 ForCES protocol entities must be authenticated per the ForCES
5006 requirements before they can access the information elements
5007 described in this document via ForCES. The ForCES protocol document
5008 [RFC5810] includes a comprehensive set of security mechanisms that
5009 implementations are required to support to meet these needs. The
5010 SCTP-based Transport Mapping Layer (TML) for the ForCES [RFC5811]
5011 specifies security mechanisms for transport mapping for ForCES
5012 protocol. The LFBs defined in this document are similar to other
5013 LFBs modeled by the FE model [RFC5812]. In particular, they have the
5014 same security properties. Thus the security mechanisms and
5015 considerations from the ForCES protocol document [RFC5810] apply and
5016 address the issues.
5018 12. References
5020 12.1. Normative References
5022 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
5023 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
5024 Control Element Separation (ForCES) Protocol
5025 Specification", RFC 5810, March 2010.
5027 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
5028 Layer (TML) for the Forwarding and Control Element
5029 Separation (ForCES) Protocol", RFC 5811, March 2010.
5031 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
5032 Element Separation (ForCES) Forwarding Element Model",
5033 RFC 5812, March 2010.
5035 12.2. Informative References
5037 [RFC1122] Braden, R., "Requirements for Internet Hosts -
5038 Communication Layers", STD 3, RFC 1122, October 1989.
5040 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
5041 RFC 1812, June 1995.
5043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
5044 Requirement Levels", BCP 14, RFC 2119, March 1997.
5046 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
5047 (IPv6) Specification", RFC 2460, December 1998.
5049 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
5050 Schoenwaelder, Ed., "Structure of Management Information
5051 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
5053 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
5054 June 1999.
5056 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
5057 Text on Security Considerations", BCP 72, RFC 3552,
5058 July 2003.
5060 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
5061 of IP Control and Forwarding", RFC 3654, November 2003.
5063 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
5064 "Forwarding and Control Element Separation (ForCES)
5065 Framework", RFC 3746, April 2004.
5067 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
5068 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
5069 May 2008.
5071 Authors' Addresses
5073 Weiming Wang
5074 Zhejiang Gongshang University
5075 18 Xuezheng Str., Xiasha University Town
5076 Hangzhou, 310018
5077 P.R.China
5079 Phone: +86 571 28877751
5080 Email: wmwang@zjsu.edu.cn
5082 Evangelos Haleplidis
5083 University of Patras
5084 Patras,
5085 Greece
5087 Email: ehalep@ece.upatras.gr
5089 Kentaro Ogawa
5090 NTT Corporation
5091 Tokyo,
5092 Japan
5094 Email: ogawa.kentaro@lab.ntt.co.jp
5096 Chuanhuang Li
5097 Hangzhou DPtech
5098 6th Floor, Zhongcai Group, 68 Tonghe Road, Binjiang District
5099 Hangzhou, 310051
5100 P.R.China
5102 Email: chuanhuang_li@zjsu.edu.cn
5104 Halpern Joel
5105 Ericsson
5106 P.O. Box 6049
5107 Leesburg, 20178
5108 VA
5110 Phone: +1 703 371 3043
5111 Email: joel.halpern@ericsson.com