draft-ietf-forces-lfb-lib-02.txt   draft-ietf-forces-lfb-lib-03.txt 
Internet Engineering Task Force W. Wang Internet Engineering Task Force W. Wang
Internet-Draft Zhejiang Gongshang University Internet-Draft Zhejiang Gongshang University
Intended status: Standards Track E. Haleplidis Intended status: Standards Track E. Haleplidis
Expires: April 20, 2011 University of Patras Expires: June 4, 2011 University of Patras
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
F. Jia C. Li
National Digital Switching Hangzhou BAUD Networks
Center(NDSC)
J. Halpern J. Halpern
Ericsson Ericsson
October 17, 2010 December 1, 2010
ForCES LFB Library ForCES Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-02 draft-ietf-forces-lfb-lib-03
Abstract Abstract
This document defines basic classes of Logical Function Blocks (LFBs) This document defines basic classes of Logical Function Blocks (LFBs)
used in the Forwarding and Control Element Separation (ForCES). It used in the Forwarding and Control Element Separation (ForCES). It
is defined according to ForCES FE model [RFC5812] and ForCES protocol is defined according to ForCES FE model [RFC5812] and ForCES protocol
[RFC5810] specifications. The basis classes of LFBs are defined to [RFC5810] specifications. These basic LFB classes are scoped to meet
meet requirements of typical router functions. Descriptions of requirements of typical router functions and considered as the basic
individual classes of LFBs are presented and detailed XML definitions LFB library for ForCES. Descriptions of individual LFBs are
are included. As use instances, several use cases of the defined presented and detailed XML definitions are included in the library.
classes of LFBs to meet typical router functions are proposed in the Several use cases of the defined LFB classes are also proposed.
document.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2011. This Internet-Draft will expire on June 4, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 25 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Scope of the Library . . . . . . . . . . . . . . . . . . . 7 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . . 7
3.2. Overview of LFB Classes in the Library . . . . . . . . . . 9 3.2. Overview of LFB Classes in the Library . . . . . . . . . . 9
3.3. Document Structure . . . . . . . . . . . . . . . . . . . . 10 3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . . 9
4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 9
4.1. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Sample LFB Class Application . . . . . . . . . . . . . 11
4.2. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Document Structure . . . . . . . . . . . . . . . . . . . . 12
4.3. MetaData . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 12 4.1. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 31 4.2. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 31 4.3. MetaData . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 31 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 15
5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . . 33 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 36
5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 35 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 36
5.1.4. EtherEncapsulator . . . . . . . . . . . . . . . . . . 36 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 36
5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 40 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . . 38
5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 40 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 40
5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 41 5.1.4. EtherEncapsulator . . . . . . . . . . . . . . . . . . 41
5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 41 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 44
5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 42 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 45
5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . . 43 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 45
5.3.2. IPv4NextHopApplicator . . . . . . . . . . . . . . . . 44 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 46
5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . . 46 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 47
5.3.4. IPv6NextHopApplicator . . . . . . . . . . . . . . . . 46 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . . 48
5.4. Address Resolution LFBs . . . . . . . . . . . . . . . . . 46 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 49
5.4.1. ARP . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . . 51
5.4.2. ND . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 51
5.5. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 48 5.4. Address Resolution LFBs . . . . . . . . . . . . . . . . . 51
5.5.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . . 48 5.4.1. ARP . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.5.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 49 5.4.2. ND . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.6. General Purpose LFBs . . . . . . . . . . . . . . . . . . . 49 5.5. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 53
5.6.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 49 5.5.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . . 53
5.6.2. GenericScheduler . . . . . . . . . . . . . . . . . . . 50 5.5.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 54
6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 52 5.6. General Purpose LFBs . . . . . . . . . . . . . . . . . . . 54
7. Use Library for Typical Router Functions . . . . . . . . . . . 77 5.6.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 54
7.1. IP Forwarding . . . . . . . . . . . . . . . . . . . . . . 77 5.6.2. GenericScheduler . . . . . . . . . . . . . . . . . . . 55
7.2. Address Resolution . . . . . . . . . . . . . . . . . . . . 78 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 57
7.3. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 83
7.4. Running Routing Protocol . . . . . . . . . . . . . . . . . 79 7.1. IP Forwarding . . . . . . . . . . . . . . . . . . . . . . 83
7.5. Network Management . . . . . . . . . . . . . . . . . . . . 79 7.2. Address Resolution . . . . . . . . . . . . . . . . . . . . 83
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.3. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81 7.4. Running Routing Protocol . . . . . . . . . . . . . . . . . 83
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 7.5. Network Management . . . . . . . . . . . . . . . . . . . . 84
11. Security Considerations . . . . . . . . . . . . . . . . . . . 83 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 85
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 86
12.1. Normative References . . . . . . . . . . . . . . . . . . . 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
12.2. Informative References . . . . . . . . . . . . . . . . . . 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12.1. Normative References . . . . . . . . . . . . . . . . . . . 89
12.2. Informative References . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Definitions 2. Definitions
This document follows the terminology defined by the ForCES This document follows the terminology defined by the ForCES
Requirements in [RFC3654]and by the ForCES framework in [RFC3746]. Requirements in [RFC3654]and by the ForCES framework in [RFC3746].
The definitions below are repeated below for clarity. The definitions below are repeated for clarity.
Control Element (CE) - A logical entity that implements the ForCES Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs on how to process protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of packets. CEs handle functionality such as the execution of
control and signaling protocols. control and signaling protocols.
Forwarding Element (FE) - A logical entity that implements the Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per- ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed/controlled by one or packet processing and handling as directed/controlled by one or
more CEs via the ForCES protocol. more CEs via the ForCES protocol.
skipping to change at page 6, line 23 skipping to change at page 6, line 23
logically interconnected and placed along the datapath within one logically interconnected and placed along the datapath within one
FE. Sometimes it is also called intra-FE topology, to be FE. Sometimes it is also called intra-FE topology, to be
distinguished from inter-FE topology. distinguished from inter-FE topology.
ForCES Protocol - While there may be multiple protocols used ForCES Protocol - While there may be multiple protocols used
within the overall ForCES architecture, the term "ForCES protocol" within the overall ForCES architecture, the term "ForCES protocol"
and "protocol" refer to the Fp reference points in the ForCES and "protocol" refer to the Fp reference points in the ForCES
Framework in [RFC3746]. This protocol does not apply to CE-to-CE Framework in [RFC3746]. This protocol does not apply to CE-to-CE
communication, FE-to-FE communication, or to communication between communication, FE-to-FE communication, or to communication between
FE and CE managers. Basically, the ForCES protocol works in a FE and CE managers. Basically, the ForCES protocol works in a
master- slave mode in which FEs are slaves and CEs are masters. master-slave mode in which FEs are slaves and CEs are masters.
This document defines the specifications for this ForCES protocol. This document defines the specifications for this ForCES protocol.
3. Introduction 3. Introduction
RFC 3746 [RFC3746] specifies Forwarding and Control Element RFC 3746 [RFC3746] specifies Forwarding and Control Element
Separation (ForCES) framework. In the framework, Control Elements Separation (ForCES) framework. In the framework, Control Elements
(CEs) configure and manage one or more separate Forwarding Elements (CEs) configure and manage one or more separate Forwarding Elements
(FEs) within a Network Element (NE) by use of a ForCES protocol. RFC (FEs) within a Network Element (NE) by use of a ForCES protocol. RFC
5810 [RFC5810] specifies the ForCES protocol. RFC 5812 [RFC5812] 5810 [RFC5810] specifies the ForCES protocol. RFC 5812 [RFC5812]
specifies the Forwarding Element (FE) model. In the model, resources specifies the Forwarding Element (FE) model. In the model, resources
in FEs are described by classes of Logical Function Blocks (LFBs). in FEs are described by classes of Logical Function Blocks (LFBs).
The FE model defines the structure and abstract semantics of LFBs, The FE model defines the structure and abstract semantics of LFBs,
and provides XML schema for the definitions of LFBs. and provides XML schema for the definitions of LFBs.
This document comforts to the specifications of the FE model This document conforms to the specifications of the FE model
[RFC5812] and specifies detailed definitions of classes of LFBs, [RFC5812] and specifies detailed definitions of classes of LFBs,
including detailed XML definitions of LFBs. These LFBs form a base including detailed XML definitions of LFBs. These LFBs form a base
LFB library for ForCES. LFBs in the base library are expected to be LFB library for ForCES. LFBs in the base library are expected to be
combined to form an LFB topology for a typical router to implement IP combined to form an LFB topology for a typical router to implement IP
forwarding. It should be emphasized that an LFB is an abstraction of forwarding. It should be emphasized that an LFB is an abstraction of
functions rather than its implementation details. The purpose of the functions rather than its implementation details. The purpose of the
LFB definitions is to represent functions so as to provide LFB definitions is to represent functions so as to provide
interoperability between separate CEs and FEs. interoperability between separate CEs and FEs.
More LFB classes with more functions may be developed in future time More LFB classes with more functions may be developed in future time
and documented by IETF. Vendors may also develop their individual and documented by IETF. Vendors may also develop proprietary LFB
LFB classes according to the FE model [RFC5812] for their specific classes as described in the FE model [RFC5812].
purposes.
3.1. Scope of the Library 3.1. Scope of the Library
It is designated that the LFB classes described in this document are It is intended that the LFB classes described in this document are
designed to provide the functions of a typical router. RFC 1812 designed to provide the functions of a typical router. RFC 1812
specifies that a typical router is expected to provide functions to: specifies that a typical router is expected to provide functions to:
(1) Interface to packet networks and implement the functions required (1) Interface to packet networks and implement the functions required
by that network. These functions typically include: by that network. These functions typically include:
o Encapsulating and decapsulating the IP datagrams with the o Encapsulating and decapsulating the IP datagrams with the
connected network framing (e.g., an Ethernet header and checksum). connected network framing (e.g., an Ethernet header and checksum).
o Sending and receiving IP datagrams up to the maximum size o Sending and receiving IP datagrams up to the maximum size
skipping to change at page 8, line 35 skipping to change at page 8, line 33
(5) Usually support an interior gateway protocol (IGP) to carry out (5) Usually support an interior gateway protocol (IGP) to carry out
distributed routing and reachability algorithms with the other distributed routing and reachability algorithms with the other
routers in the same autonomous system. In addition, some routers routers in the same autonomous system. In addition, some routers
will need to support an exterior gateway protocol (EGP) to exchange will need to support an exterior gateway protocol (EGP) to exchange
topological information with other autonomous systems. topological information with other autonomous systems.
(6) Provide network management and system support facilities, (6) Provide network management and system support facilities,
including loading, debugging, status reporting, exception reporting including loading, debugging, status reporting, exception reporting
and control. and control.
Within the ForCES framework, according to the ForCES protocol The classical IP router utilizing the ForCES framework constitutes a
[RFC5810] and the FE model [RFC5812] specifications, above typical CE running some controlling IGP and/or EGP function and FEs
router functions should be implemented under the concept of Logical implementing using Logical Function Blocks (LFBs) conforming to the
Functional Blocks (LFBs). Taking a typical IP forwarding function as FE model[RFC5812] specifications. The CE, in conformance to the
an example, some port LFBs receive packets and decapsulate the IP ForCES protocol[RFC5810] and the FE model [RFC5812] specifications,
datagrams to form IP level packets. Different port media have instructs the LFBs on the FE how to treat received/sent packets. In
different manipulating requirements from CE, therefore various port a typical packet flow within an IP router, a port LFB receives
LFBs for various media may have to be defined. IP packets from port packets and decapsulates them to form IP level packets. Different
LFBs are then validated before being further forwarded. A kind of port media will have different ways to achieve the goal of
valildation LFBs are applied for the purpose. After validation decapsulating media-specific headers and therefore LFBs for various
process, some LFBs for IP forwarding may then be applied. In the media will have to be defined although this document sticks to
Forwarding LFBs, a Longest Prefix Match LFB is used to look up the ethernet only. IP packets emanating from port LFBs are then
destination information in a packet and select a next hop index for processed by a validation LFB before being further forwarded to the
sending the packet onward. A next hop applicator LFB uses the next next LFB. After the validation process the packet is passed to an
hop index metadata to apply the proper headers to the IP packets, and LFB where IP forwarding decision is made. In the IP Forwarding LFBs,
direct them to the proper egress. a Longest Prefix Match LFB is used to look up the destination
information in a packet and select a next hop index for sending the
packet onward. A next hop LFB uses the next hop index metadata to
apply the proper headers to the IP packets, and direct them to the
proper egress. Note that in the process of IP packets processing, in
this document, we are adhering to the weak host model[RFC1122] since
that is the most usable model for a packet processing Network
Element(NE). (Editorial note - describe how a strong host model is
achieved if needed.)
3.2. Overview of LFB Classes in the Library 3.2. Overview of LFB Classes in the Library
It is critical to classify functional requirements into various It is critical to classify functional requirements into various
classes of LFBs and construct a typical but also flexible enough base classes of LFBs and construct a typical but also flexible enough base
LFB library for various IP forwarding equipments. In the process, LFB library for various IP forwarding equipments.
some principles may be applied:
(1)if a function can be designed by either one LFB or two or more 3.2.1. LFB Design Choices
LFBs with the same cost, it will be designed by two or more LFBs so
as to provide more flexibility for implementers.
(2)when flexibility is not required, an LFB should take advantage of A few design principles were factored into choosing how the base LFBs
its as much as possible independence and leave least couples with looked like. These are:
other LFBs. The couples may be from LFB attributes definitions as
well as physical implementations.
(3)unless there is a difference in actual functionality, it should o if a function can be designed by either one LFB or two or more
not represent the same thing in two different fashions. Or else, it LFBs with the same cost, the choice is to go with two or more LFBs
may add extra burden on implementation. so as to provide more flexibility for implementers.
o when flexibility is not required, an LFB should take advantage of
its independence as much as possible and have minimal coupling
with other LFBs. The coupling may be from LFB attributes
definitions as well as physical implementations.
o unless there is a clear difference in functionality, similar
packet processing should not be represented as two or more
different LFBs. Or else, it may add extra burden on
implementation to achieve interoperability.
3.2.2. LFB Class Groupings
The document defines groups of LFBs for typical router function The document defines groups of LFBs for typical router function
requirements: requirements:
o A group of Ethernet processing LFBs are defined to abstract the (1) A group of Ethernet processing LFBs are defined to abstract the
packet processing for Ethernet as the port media type. As the packet processing for Ethernet as the port media type. As the most
most popular media type with rich processing features, Ethernet popular media type with rich processing features, Ethernet media
media processing LFBs also provide typical work for other media processing LFBs was a natural choice. Definitions for processing of
types. Definitions for processing of other port media types like other port media types like POS or ATM may be incorporated in the
POS or ATM may be incorporated in the library in future version of library in future version of the document or in a future separate
the document. document.
o A group of LFBs are defined for IP packet validation process. The following LFBs are defined for Ethernet processing:
Actually, only one LFB is currently defined specifi for individual
IPv4 or IPv6 protocol validations.
o A group of LFBs are defined to abstract IP forwarding process. A EtherPHYCop (Section 5.1.1)
unicast longest prefix match LFB and a followed next hop EtherMACIn (section 5.1.2)
applicator LFB are applied to IP forwarding process. Forwarding
process for IPv4 and IPv6 packets are separated, therefore LFBs
specifically for IPv4 and IPv6 are separately defined.
o A group of address resolution LFBs are defined for the purpose to EtherClassifier (section 5.1.3)
abstract the process for address resolution function. Actually,
there is only one LFB defined for individual IPv4 or IPv6 address
resolution or neighbor discovery. In IPv4 case, the LFB is called
ARP LFB and in IPv6 case, the LFB is called ND(neighbor discovery)
LFB.
o A group of LFBs are defined to abstract the process for redirect EtherEncapsulator (section 5.1.4)
operation, i.e., data packet transmission between CE and FEs. A
RedirectIn LFB describes the process for CE to inject packets to
FE LFB paths, and a RedirectOut LFB abstracts the process for
various FE LFBs to send data packets to CE.
o A group of LFBs are defined for abstracting some general purpose EtherMACOut (section 5.1.5)
packet processing. These processing processes are usually general
to many processing locations in some FE LFB topology. Currently,
two such LFBs are defined, a generic dispatch LFB and a generic
scheduler LFB.
3.3. Document Structure (2) A group of LFBs are defined for IP packet validation process.
For every group of LFB classes, a set of LFBs are defined for The following LFBs are defined for IP Validation processing:
individual function purposes. Section 6 (LFB Descriptions Section)
makes text descriptions in details on individual LFBs. Note that for
a complete definition of an LFB, a text description as well as a XML
definition is required.
Section 8 provides more detailed descriptions on how various typical IPv4Validator (section 5.2.1)
router functions are implemented based on the defined base LFB
classes.
To define various LFB classes, a set of base type definitions with IPv6Validator (section 5.2.2)
the data types, packet frame types, and metadata types have to be
specified in advance. Section 5 (Base Types Section) provide a (3) A group of LFBs are defined to abstract IP forwarding process.
description on the base types used by this LFB library. In order to
provide an extensive use of these base types for other LFB The following LFBs are defined for IP Forwarding processing:
definitions, the base type definitions are provided by a specific xml
file as a base type library which is separate from the LFB definition IPv4UcastLPM (section 5.3.1)
library.
IPv4NextHop (section 5.3.2)
IPv6UcastLPM (section 5.3.4)
IPv6NextHop (section 5.3.4)
(4) A group of address resolution LFBs are defined for the purpose to
abstract the process for address resolution function.
The following LFBs are defined for Address Resolution processing:
ARP (section 5.4.1)
ND (section 5.4.2)
(5) A group of LFBs are defined to abstract the process for redirect
operation, i.e., data packet transmission between CE and FEs.
The following LFBs are defined for redirect processing:
RedirectIn (section 5.5.1)
RedirectOut (section 5.5.2)
(6) A group of LFBs are defined for abstracting some general purpose
packet processing. These processing processes are usually general to
many processing locations in an FE LFB topology.
The following LFBs are defined for redirect processing:
BasicMetadataDispatch (section 5.6.1)
GenericScheduler (section 5.6.2)
3.2.3. Sample LFB Class Application
Although Section 7 will present use cases for LFBs defined in this
document, this section shows a sample LFB class application in
advance so that readers can get a quick overlook of the LFB classes.
Figure 1 shows the typical LFB processing path for the IPv4 unicast
forwarding case with Ethernet media interfaces. Section 7.1 will
describe the LFB topology in more details.
+-----+ +------+
| | | |
| |<---------------|Ether |<----------------------------+
| | |MACOut| |
| | | | |
|Ether| +------+ |
|PHY | |
|Cop | +---+ |
|#1 | +-----+ | |----->IPv6 Packets |
| | | | | | +----+ |
| | |Ether| | | | | |
| |->|MACIn|-->| |IPv4| | |
+-----+ | | | |-+->| | +---+ |
+-----+ +--+ | | |unicast +-----+ | | |
Ether | | |------->| | | | |
. Classifier| | |packet |IPv4 | | | |
. | | | |Ucast|->| |--+ |
. | | | |LPM | | | | |
+---+ | +----+ +-----+ | | | |
+-----+ | | | IPv4 +---+ | |
| | | | | Validator IPv4 | |
+-----+ |Ether| | |-+ NextHop | |
| |->|MACIn|-->| |IPv4 | |
| | | | | |----->IPv6 Packets | |
|Ether| +-----+ +---+ +----+ | |
|PHY | Ether | | | |
|Cop | Classifier | | +-------+ | |
|#n | | | | | | |
| | +------+ | |<--| Ether |<-+ |
| | | |<------| | | Encap | |
| |<---------------|Ether | ...| | +-------+ |
| | |MACOut| +---| | |
| | | | | +----+ |
+-----+ +------+ | BasicMetadataDispatch |
+-------------------------+
Figure 1: A Sample of LFB Class Application
3.3. Document Structure
Base type definitions, including data types, packet frame types, and
metadata types are presented in advance for definitions of various
LFB classes. Section 4 (Base Types Section) provide a description on
the base types used by this LFB library. In order for an extensive
use of these base types for other LFB class definitions, the base
type definitions are provided by an xml file in a way as a library
which is separate from the LFB definition library.
Within every group of LFB classes, a set of LFBs are defined for
individual function purposes. Section 5 (LFB Class Descriptions
Section) makes text descriptions on the individual LFBs. Note that
for a complete definition of an LFB, a text description as well as a
XML definition is required.
LFB classes are finally defined by XML with specifications and schema LFB classes are finally defined by XML with specifications and schema
from the ForCES FE model[RFC5812]. Section 6 (LFB Definitions defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB
Section) provide the complete XML definitions of the base LFB classes Definitions Section) provide the complete XML definitions of the base
library. LFB classes library.
Section 7 provides several use cases on how some typical router
functions can be implemented using the base LFB library defined in
this document.
4. Base Types 4. Base Types
The FE model [RFC5812] has specified the following data types as The FE model [RFC5812] has specified the following data types as
predefined (built-in) atomic data-types: predefined (built-in) atomic data-types:
char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
string, byte[N], boolean, octetstring[N], float16, float32, float64. string, byte[N], boolean, octetstring[N], float16, float32, float64.
Based on these atomic data types and with the use of type definition Based on these atomic data types and with the use of type definition
skipping to change at page 12, line 24 skipping to change at page 15, line 24
(TBD) (TBD)
4.4. XML for Base Type Library 4.4. XML for Base Type Library
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseTypeLibrary"> provides="BaseTypeLibrary">
<frameDefs> <frameDefs>
<frameDef> <frameDef>
<name>EthernetAll</name>
<synopsis>An kinds of Ethernet frame</synopsis>
</frameDef>
<frameDef>
<name>EthernetII</name> <name>EthernetII</name>
<synopsis>An Ethernet II frame</synopsis> <synopsis>An Ethernet II frame</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>ARP</name> <name>ARP</name>
<synopsis>an arp packet</synopsis> <synopsis>an arp packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv4</name> <name>IPv4</name>
<synopsis>An IPv4 packet</synopsis> <synopsis>An IPv4 packet</synopsis>
skipping to change at page 16, line 28 skipping to change at page 19, line 32
</component> </component>
<component componentID="10"> <component componentID="10">
<name>OutErrorPkts</name> <name>OutErrorPkts</name>
<synopsis>Number of output error packets</synopsis> <synopsis>Number of output error packets</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
<!-- XXX: Make sure we validate with SNMP Port Stats --> <!-- XXX: Make sure we validate with SNMP Port Stats -->
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>PHYPortStatsType</name> <name>MACInStatsType</name>
<synopsis>The content of statistic for EtherPHYCop.</synopsis> <synopsis>The content of statistic for EtherMACIn.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>NumPacketsReceived</name> <name>NumPacketsReceived</name>
<synopsis>The number of packets received.</synopsis> <synopsis>The number of packets received.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>NumPacketsDroped</name>
<synopsis>The number of packets droped.</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MACOutStatsType</name>
<synopsis>The content of statistic for EtherMACOut.</synopsis>
<struct>
<component componentID="1">
<name>NumPacketsTransimtted</name> <name>NumPacketsTransimtted</name>
<synopsis>The number of packets transimtted.</synopsis> <synopsis>The number of packets transimtted.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> <component componentID="2">
<name>NumPacketsDroped </name> <name>NumPacketsDroped</name>
<synopsis>The number of packets droped.</synopsis> <synopsis>The number of packets droped.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MACStatsType</name>
<synopsis>The content of statistic for EtherPHYCop.</synopsis>
<typeRef>contents</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>EtherDispatchTableType</name> <name>EtherDispatchTableType</name>
<synopsis>the type of etherDispatch table entry.</synopsis> <synopsis>the type of etherDispatch table entry.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>LogicalPortID</name> <name>LogicalPortID</name>
<synopsis>Logical port ID.</synopsis> <synopsis>Logical port ID.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>EtherType</name> <name>EtherType</name>
skipping to change at page 18, line 49 skipping to change at page 22, line 11
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6ValidatorStatisticsType</name> <name>IPv6ValidatorStatisticsType</name>
<synopsis>Statistics type in IPv6validator.</synopsis> <synopsis>Statistics type in IPv6validator.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>badHeaderPkts</name> <name>badHeaderPkts</name>
<synopsis>Number of bad header packets.</synopsis> <synopsis>Number of bad header packets.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>badTotalLengthPkts</name> <name>badTotalLengthPkts</name>
<synopsis>Number of bad total length packets.</synopsis> <synopsis>Number of bad total length packets.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>badHopLimitPkts</name> <name>badHopLimitPkts</name>
<synopsis>Number of bad Hop limit packets.</synopsis> <synopsis>Number of bad Hop limit packets.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4PrefixTableType</name> <name>IPv4PrefixTableType</name>
<synopsis>Each row of the IPv4 Prefix Table</synopsis> <synopsis>Each row of the IPv4 Prefix Table</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IPv4Address</name> <name>IPv4Address</name>
<synopsis>An IPv4 Address</synopsis> <synopsis>An IPv4 Address</synopsis>
skipping to change at page 20, line 34 skipping to change at page 23, line 44
<name>True</name> <name>True</name>
<synopsis>This route is a default route. for <synopsis>This route is a default route. for
supporting the loose RPF.</synopsis> supporting the loose RPF.</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4UcastLPMStatsType</name>
<synopsis>Statistics type in IPv4Unicast.</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>The total number of input packets
received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>IPv4 packets forwarded by this LFB</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because
no route could be found.</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6PrefixTableType</name> <name>IPv6PrefixTableType</name>
<synopsis>Each row of the IPv6 Prefix Table</synopsis> <synopsis>Each row of the IPv6 Prefix Table</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IPv6Address</name> <name>IPv6Address</name>
<synopsis>An IPv6 Address</synopsis> <synopsis>An IPv6 Address</synopsis>
<typeRef>IPv6Addr</typeRef> <typeRef>IPv6Addr</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>Prefixlen</name> <name>Prefixlen</name>
skipping to change at page 21, line 51 skipping to change at page 25, line 36
<name>True</name> <name>True</name>
<synopsis>This route is a default route. <synopsis>This route is a default route.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6UcastLPMStatsType</name>
<synopsis>Statistics type in IPv6Unicast.</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>The total number of input packets
received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>IPv6 packets forwarded by this LFB</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because
no route could be found.</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>NexthopOptionType</name> <name>NexthopOptionType</name>
<synopsis>Special Values of NextHopOption Type</synopsis> <synopsis>Special Values of NextHopOption Type</synopsis>
<atomic> <atomic>
<baseType>uint8</baseType> <baseType>uint8</baseType>
<specialValues> <specialValues>
<specialValue value="1"> <specialValue value="1">
<name>Normal</name> <name>Normal</name>
<synopsis>Normal Forwarding</synopsis> <synopsis>Normal Forwarding</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
skipping to change at page 23, line 11 skipping to change at page 27, line 19
<typeRef>NexthopOptionType</typeRef> <typeRef>NexthopOptionType</typeRef>
</component> </component>
<component componentID="6"> <component componentID="6">
<name>EncapOutputIndex</name> <name>EncapOutputIndex</name>
<synopsis>Group output port index</synopsis> <synopsis>Group output port index</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6NextHopTableType</name>
<synopsis>Each row of the IPv4 NextHop Table</synopsis>
<struct>
<component componentID="1">
<name>NexthopID</name>
<synopsis>ID of the NextHop</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>OutputLogicalPortID</name>
<synopsis>The ID of the Logical OutputPort</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>MTU</name>
<synopsis>Maximum Transmission Unit for out going port.
It is for desciding whether the packet need fragmentation
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>NexthopIPAddr</name>
<synopsis>Next Hop IPv4 Address</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="5">
<name>NexthopOption</name>
<synopsis>Next Hop Option</synopsis>
<typeRef>NexthopOptionType</typeRef>
</component>
<component componentID="6">
<name>EncapOutputIndex</name>
<synopsis>Group output port index</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>ArpTableType</name> <name>ArpTableType</name>
<synopsis>ARP table entry type.</synopsis> <synopsis>ARP table entry type.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>LogicalPortID</name> <name>LogicalPortID</name>
<synopsis>Logical port ID.</synopsis> <synopsis>Logical port ID.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>DstIPv4Address</name> <name>DstIPv4Address</name>
skipping to change at page 26, line 40 skipping to change at page 31, line 38
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>QueueDepthInBytes</name> <name>QueueDepthInBytes</name>
<synopsis>the Queue Depth when the depth units <synopsis>the Queue Depth when the depth units
are bytes.</synopsis> are bytes.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef>
<name>MetaDispatchTableType</name>
<synopsis>Metadata dispatch table type.</synopsis>
<struct>
<component componentID="1">
<name>metadataID</name>
<synopsis>metadata ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MetadataValue</name>
<synopsis>metadata value.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>OutputIndex</name>
<synopsis>group output port index.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
</dataTypeDefs> </dataTypeDefs>
<metadataDefs> <metadataDefs>
<metadataDef> <metadataDef>
<name>PHYPortID</name> <name>PHYPortID</name>
<synopsis>The physical port ID that a packet has entered. <synopsis>The physical port ID that a packet has entered.
</synopsis> </synopsis>
<metadataID>1</metadataID> <metadataID>1</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
skipping to change at page 31, line 14 skipping to change at page 36, line 14
5. LFB Class Description 5. LFB Class Description
According to ForCES specifications, LFB (Logical Function Block) is a According to ForCES specifications, LFB (Logical Function Block) is a
well defined, logically separable functional block that resides in an well defined, logically separable functional block that resides in an
FE, and is a functionally accurate abstraction of the FE's processing FE, and is a functionally accurate abstraction of the FE's processing
capabilities. An LFB Class (or type) is a template that represents a capabilities. An LFB Class (or type) is a template that represents a
fine-grained, logically separable aspect of FE processing. Most LFBs fine-grained, logically separable aspect of FE processing. Most LFBs
are related to packet processing in the data path. LFB classes are are related to packet processing in the data path. LFB classes are
the basic building blocks of the FE model. Note that RFC 5810 has the basic building blocks of the FE model. Note that RFC 5810 has
already defined an 'FE Protocol LFB' that is defined as a logical already defined an 'FE Protocol LFB' which is as a logical entity in
entity in each FE to control the ForCES protocol. RFC 5812 has each FE to control the ForCES protocol. RFC 5812 has already defined
already defined an 'FE Object LFB' that is defined to make the FE an 'FE Object LFB'. Information like the FE Name, FE ID, FE State,
information easily accessible to CE. Information like the FE Name, LFB Topology in the FE are represented in this LFB.
FE ID, FE State, LFB Topology in the FE are represented in this LFB.
As mentioned in section 3, this document intends to provide a base As specified in Section 3.1, this document focuses the base LFB
LFB library for implementing typical router functions, especially for library for implementing typical router functions, especially for IP
IP forwarding functions. As a result, LFB classes defined here are forwarding functions. As a result, LFB classes in the library are
base LFBs to implement router forwarding. all base LFBs to implement router forwarding.
5.1. Ethernet Processing LFBs 5.1. Ethernet Processing LFBs
As the most popular physical and data link layer protocols, Ethernets As the most popular physical and data link layer protocols, Ethernets
are widely deployed. It becomes a basic requirement for a router to are widely deployed. It becomes a basic requirement for a router to
be able to process various Ethernet data packets. be able to process various Ethernet data packets.
Note that there exist different versions of Ethernet protocols, like Note that there exist different versions of Ethernet protocols, like
Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP.
There also exist varieties of LAN techniques based on Ethernet, like There also exist varieties of LAN techniques based on Ethernet, like
skipping to change at page 32, line 8 skipping to change at page 37, line 7
layer. It limits the physical media to copper. layer. It limits the physical media to copper.
The LFB is defined with one singleton input. The input data of the The LFB is defined with one singleton input. The input data of the
LFB are expected to be Ethernet packets. Note that Ethernet packets LFB are expected to be Ethernet packets. Note that Ethernet packets
here cover all packets encapsulated with different versions of here cover all packets encapsulated with different versions of
Ethernet protocols, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, Ethernet protocols, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2,
IEEE 802.3/802.2 SNAP. It also includes packets encapsulated with IEEE 802.3/802.2 SNAP. It also includes packets encapsulated with
varieties of LAN techniques based on Ethernet, like various VLANs, varieties of LAN techniques based on Ethernet, like various VLANs,
MACinMAC, etc. As a result, we define various Ethernet frames as a MACinMAC, etc. As a result, we define various Ethernet frames as a
frame name called 'EthernetAll'. In an LFB abstracted processing frame name called 'EthernetAll'. In an LFB abstracted processing
path in an FE, usually the Ethernet packets are from an upstream LFB path, usually the Ethernet packets are from an upstream LFB like an
like an EtherMACOut LFB. It is not expected that an input Ethernet EtherMACOut LFB. It is not expected that an input Ethernet packet be
packet be associated with some metadata. After the LFB receives the associated with some metadata. After the LFB receives the Ethernet
Ethernet packets, it will further process the packets at physical packets, it will further process the packets at physical layer and
layer and eventually put them on the physical media wire for eventually put them on the physical media wire for transmission.
transmission. Note that the media wire transmission process in the Note that the media wire transmission process in the LFB is
LFB is abstracted as a default function of the LFB rather than an abstracted as a default function of the LFB rather than an input or
input or output interface of the LFB. output interface of the LFB.
The LFB is also defined with one singleton output. The output data The LFB is also defined with one singleton output. The output data
produced are also with 'EthernetAll' frame type. Every output data produced are also with 'EthernetAll' frame type. Every output data
packet is associated with a 'PHYPortID' metadata to indicate later packet is associated with a 'PHYPortID' metadata to indicate later
processing LFBs of which physical port the packet is from. Note that processing LFBs of which physical port the packet is from. Note that
all the data packets are originated from media wire inside the LFB, all the data packets are originated from media wire inside the LFB,
which is defined as a default function of the LFB. As a physical which is defined as a default function of the LFB. As a physical
layer abstraction module, the LFB does not possess the ability to layer abstraction module, the LFB does not possess the ability to
specify encapsulations of types of Ethernet, rather, it produces specify encapsulations of types of Ethernet, rather, it produces
various Ethernet types just according to what it receives from various Ethernet types just according to what it receives from
skipping to change at page 32, line 39 skipping to change at page 37, line 38
Note that as a base definition, functions like multiple virtual Note that as a base definition, functions like multiple virtual
physical layers are not supported in this LFB version. It may be physical layers are not supported in this LFB version. It may be
supported in the future by defining a subclass or a new version of supported in the future by defining a subclass or a new version of
this LFB. this LFB.
Several components are defined for the LFB. Several components are defined for the LFB.
AdminStatus is defined for CE to administratively manage the status AdminStatus is defined for CE to administratively manage the status
of the LFB. Via the component, CE may startup or shutdown the LFB. of the LFB. Via the component, CE may startup or shutdown the LFB.
The default status is set to 'Down'. Note that as a physical layer The default status is set to 'Down'. An OperStatus component is
LFB for whole Ethernet processing, the administrative status specifically defined for CE to access the actual operational status
configuration of this LFB will simultaneously affect status of of the LFB, in case that a physical layer port may be in a failed
related Ethernet processing LFBs. An 'Up' or 'Down' of the LFB state that its operational status does not correctly reflect
actually mean the whole Ethernet interface 'Up' or 'Down' with all administrative status. A PHYPortStatusChanged event is defined for
the Ethernet processing ability. To meet this, A OperStatus the LFB to report to CE whenever there is a port status change during
component is defined in all Ethernet related processing LFBs like operation.
EtherMACIn, EtherClassifier, EtherEncap, and EtherMACOut LFBs to
reflect the physical layer administrative status. A
PHYPortStatusChanged event is defined for the LFB to report to CE
whenever there is a port status change during operation.
PHYPortID component is defined for CE to assign an ID to the physical PHYPortID component is defined for CE to assign an ID to the physical
port. The component will be used to produce a metadata associated port. The component will be used to produce a metadata associated
with every Ethernet packet the LFB receives from media and is going with every Ethernet packet the LFB receives from media and is going
to hand to later LFBs for further processing. to hand to later LFBs for further processing.
A group of components are defined for link speed management. The A group of components are defined for link speed management. The
AdminLinkSpeed is for CE to configure proper link speed for the port AdminLinkSpeed is for CE to configure proper link speed for the port
and the OperLinkSpeed is for CE to query the actual link speed in and the OperLinkSpeed is for CE to query the actual link speed in
operation. The default value for the AdminLinkSpeed is set to auto- operation. The default value for the AdminLinkSpeed is set to auto-
negotiation mode. A SupportedLinkSpeed capability attribute is also negotiation mode. A SupportedLinkSpeed capability attribute is also
defined for CE to query the link speed ability. A LinkSpeedChanged defined for CE to query the link speed ability. A LinkSpeedChanged
event is defined for the LFB to report to CE whenever there is a link event is defined for the LFB to report to CE whenever there is a link
speed change during operation. speed change during operation.
A group of components are defined for duplex mode management. The A group of components are defined for duplex mode management. The
AdminDuplexMode is for CE to configure proper duplex mode for the AdminDuplexMode is for CE to configure proper duplex mode for the
port and the OperDuplexMode is for CE to query the actual duplex mode port and the OperDuplexMode is for CE to query the actual duplex mode
in operation. The default value for the AdminDuplexMode is set to in operation. The default value for the AdminDuplexMode is set to
auto-negotiation mode. A SupportedDuplexMode capability is also auto-negotiation mode. A SupportedDuplexMode capability is also
defined for CE to query the port duplex mode ability. defined for CE to query the port duplex mode ability. A
DuplexModeChanged event is defined for the LFB to report to CE
whenever there is a duplex mode change during operation.
There are also some other components, capabilities, events defined in There are also some other components, capabilities, events defined in
the LFB for various purposes. See section 6 for detailed XML the LFB for various purposes. See section 6 for detailed XML
definitions of the LFB. definitions of the LFB.
5.1.2. EtherMACIn 5.1.2. EtherMACIn
EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. It EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. It
specifically describes Ethernet processing functions like MAC address specifically describes Ethernet processing functions like MAC address
locality check, deciding if the Ethernet packets should be bridged, locality check, deciding if the Ethernet packets should be bridged,
skipping to change at page 34, line 49 skipping to change at page 39, line 46
implemented is vendor-specific. As an abstraction, this LFB defines implemented is vendor-specific. As an abstraction, this LFB defines
two flag components for CE to enable or disable the flow control two flag components for CE to enable or disable the flow control
functions. The flow control is further distinguished by Tx flow functions. The flow control is further distinguished by Tx flow
control and Rx flow control, separately for sending process and control and Rx flow control, separately for sending process and
receiving process flow controls. A TxFlowControl flag and a receiving process flow controls. A TxFlowControl flag and a
RxFlowControl flag are then separately defined. In order for RxFlowControl flag are then separately defined. In order for
EtherMACOut LFB able to cooperatively work for flow control, the EtherMACOut LFB able to cooperatively work for flow control, the
flags are also referenced in the EtherMACOut LFB as aliases in this flags are also referenced in the EtherMACOut LFB as aliases in this
LFB. LFB.
An OperStatus component is also defined in the LFB for CE to read AdminStatus is defined for CE to administratively manage the status
operation status of the LFB. Note that the status will be of the LFB. Via the component, CE can startup or shutdown the LFB.
administratively managed via AdminStatus in the physical port LFB The default status is set to 'Down'. /
that the LFB usually rely on. /*how to describe the relationship
between the adminstatus and the operstatus is still a problem */
Note that as a base definition, functions like multiple virtual MAC Note that as a base definition, functions like multiple virtual MAC
layers are not supported in this LFB version. It may be supported in layers are not supported in this LFB version. It may be supported in
the future by defining a subclass or a new version of this LFB. the future by defining a subclass or a new version of this LFB.
There are also some other components, capabilities, events defined in There are also some other components, capabilities, events defined in
the LFB for various purposes. See section 6 for detailed XML the LFB for various purposes. See section 6 for detailed XML
definitions of the LFB. definitions of the LFB.
5.1.3. EtherClassifier 5.1.3. EtherClassifier
skipping to change at page 36, line 51 skipping to change at page 41, line 46
the LFB for various purposes. See section 6 for detailed XML the LFB for various purposes. See section 6 for detailed XML
definitions of the LFB. definitions of the LFB.
5.1.4. EtherEncapsulator 5.1.4. EtherEncapsulator
EtherEncapsulator LFB abstracts the process to encapsulate IP packets EtherEncapsulator LFB abstracts the process to encapsulate IP packets
to Ethernet packets. to Ethernet packets.
Input of the LFB expects types of IP packets, including IPv4 and IPv6 Input of the LFB expects types of IP packets, including IPv4 and IPv6
types. The input is a singleton one which may connect to an upstream types. The input is a singleton one which may connect to an upstream
LFB like an IPv4NextHopApplicator, an IPv6NextHopApplicator, or any LFB like an IPv4NextHop, an IPv6NextHop, or any LFB which requires to
LFB which requires to output packets for Ethernet encapsulation. The output packets for Ethernet encapsulation. The input is capable of
input is capable of multiplexing to allow for multiple upstream LFBs multiplexing to allow for multiple upstream LFBs being connected.
being connected. For instance, an IPv4NextHopApplicator or an For instance, an IPv4NextHop or an IPv6NextHop may concurrently
IPv6NextHopApplicator may concurrently exist, and some L2 bridging exist, and some L2 bridging LFBs may also output packets to this LFB
LFBs may also output packets to this LFB simultaneously. Input of simultaneously. Input of this LFB is capable of handling this case.
this LFB is capable of handling this case. Usually, every input
Ethernet packet is expected to be associated with an output logical Usually, every input Ethernet packet is expected to be associated
port ID and a next hop IP address as its metadata. In the case when with an output logical port ID and a next hop IP address as its
L2 bridging function is implemented, an input packet may also metadata. In the case when L2 bridging function is implemented, an
optionally receive a VLAN priority as its metadata. In this case, input packet may also optionally receive a VLAN priority as its
default value for this metadata is set to 0. metadata. In this case, default value for this metadata is set to 0.
There are several outputs for this LFB. One singleton output is for There are several outputs for this LFB. One singleton output is for
normal success packet output. Packets which have found Ethernet L2 normal success packet output. Packets which have found Ethernet L2
information and have been successfully encapsulated to an Ethernet information and have been successfully encapsulated to an Ethernet
packet will output from this port to downstream LFB. Note that this packet will output from this port to downstream LFB. Note that this
LFB specifies to use Ethernet II as its Ethernet encapsulation type. LFB specifies to use Ethernet II as its Ethernet encapsulation type.
Success output also produces an output logical port ID as metadatum Success output also produces an output logical port ID as metadatum
of every output packet for a downstream LFB to decide which logical of every output packet for a downstream LFB to decide which logical
port the packet should go out. The downstream LFB usually dispatches port the packet should go out. The downstream LFB usually dispatches
the packets based on its associated output logical port ID. Hence, a the packets based on its associated output logical port ID. Hence, a
skipping to change at page 40, line 36 skipping to change at page 45, line 29
output is PHYPortID, which keeps indicating which physical port the output is PHYPortID, which keeps indicating which physical port the
packet is to. packet is to.
Ethernet layer flow control is usually implemented cooperatively by Ethernet layer flow control is usually implemented cooperatively by
EtherMACIn LFB and EtherMACOut LFB. How the flow control is EtherMACIn LFB and EtherMACOut LFB. How the flow control is
implemented is vendor-specific. As an abstraction, this LFB defines implemented is vendor-specific. As an abstraction, this LFB defines
two flag components for CE to enable or disable the flow control two flag components for CE to enable or disable the flow control
functions, a TxFlowControl flag and a RxFlowControl flag, and they functions, a TxFlowControl flag and a RxFlowControl flag, and they
are all defined as aliases of EtherMACIn LFB. are all defined as aliases of EtherMACIn LFB.
An OperStatus component is also defined in the LFB as an alias of AdminStatus is defined for CE to administratively manage the status
EtherMACIn LFB, so as for CE to read operation status of the LFB. of the LFB. Via the component, CE can startup or shutdown the LFB.
The default status is set to 'Down'.
Note that as a base definition, functions like multiple virtual MAC Note that as a base definition, functions like multiple virtual MAC
layers are not supported in this LFB version. It may be supported in layers are not supported in this LFB version. It may be supported in
the future by defining a subclass or a new version of this LFB. the future by defining a subclass or a new version of this LFB.
There are also some other components, capabilities, events defined in There are also some other components, capabilities, events defined in
the LFB for various purposes. See section 6 for detailed XML the LFB for various purposes. See section 6 for detailed XML
definitions of the LFB. definitions of the LFB.
5.2. IP Packet Validation LFBs 5.2. IP Packet Validation LFBs
An LFB is defined to abstract IP packet validation process. An An LFB is defined to abstract IP packet validation process. An
IPv4Validator LFB is specifically for IPv4 protocol validation and an IPv4Validator LFB is specifically for IPv4 protocol validation and an
IPv6Validator LFB for IPv6. IPv6Validator LFB for IPv6.
5.2.1. IPv4Validator 5.2.1. IPv4Validator
This LFB performs IPv4 packets validation according to RFC 1812 and This LFB performs IPv4 packets validation according to RFC 1812.
RFC 2644.
Input of the LFB always expects packets which have been indicated as Input of the LFB always expects packets which have been indicated as
IPv4 packets by an upstream LFB, like an EtherClassifier LFB. There IPv4 packets by an upstream LFB, like an EtherClassifier LFB. There
is no specific metadata expected by the input of the validator LFB. is no specific metadata expected by the input of the validator LFB.
Note that, as a default provision of RFC 5812, in FE model, all Note that, as a default provision of RFC 5812, in FE model, all
metadata produced by upstream LFBs will pass through all downstream metadata produced by upstream LFBs will pass through all downstream
LFBs by default without being specified by input port or output port. LFBs by default without being specified by input port or output port.
Only those metadata that will be used(consumed) by an LFB will be Only those metadata that will be used(consumed) by an LFB will be
explicitly marked in input of the LFB as expected metadata. For explicitly marked in input of the LFB as expected metadata. For
skipping to change at page 41, line 51 skipping to change at page 46, line 44
A singleton output is defined for all packets which have failed the A singleton output is defined for all packets which have failed the
packet validation. A validate error ID is associated to every failed packet validation. A validate error ID is associated to every failed
packet to indicate the reasons like an invalid packet size, wrong IP packet to indicate the reasons like an invalid packet size, wrong IP
protocol version, wrong checksum, etc. protocol version, wrong checksum, etc.
There are also some other components defined in the LFB for various There are also some other components defined in the LFB for various
purposes. See section 6 for detailed XML definitions of the LFB. purposes. See section 6 for detailed XML definitions of the LFB.
5.2.2. IPv6Validator 5.2.2. IPv6Validator
This LFB performs IPv6 packets validation according to RFC 2460 and This LFB performs IPv6 packets validation according to RFC 2460.
RFC 4291.
Input of the LFB always expects packets which have been indicated as Input of the LFB always expects packets which have been indicated as
IPv6 packets by an upstream LFB like an EtherClassifier LFB. There IPv6 packets by an upstream LFB like an EtherClassifier LFB. There
is no specific metadata expected by the input of the validator LFB. is no specific metadata expected by the input of the validator LFB.
Similar to IPv4 validator LFB, IPv6Validator LFB has also defined Similar to IPv4 validator LFB, IPv6Validator LFB has also defined
four output ports to output various validation results. All four output ports to output various validation results. All
validated IPv6 unicast packets will be output at the singleton validated IPv6 unicast packets will be output at the singleton
IPv6UnicastOut port. All validated IPv6 multicast packets will be IPv6UnicastOut port. All validated IPv6 multicast packets will be
output at the singleton IPv6MulticastOut port. There is no metadata output at the singleton IPv6MulticastOut port. There is no metadata
skipping to change at page 44, line 33 skipping to change at page 49, line 27
various RPF, one or more specific LFBs have to be defined. This job various RPF, one or more specific LFBs have to be defined. This job
may be done for the future version of the library. may be done for the future version of the library.
An exception output is defined to allow some exceptional packets to An exception output is defined to allow some exceptional packets to
output here. Exceptions include cases like packets can not find any output here. Exceptions include cases like packets can not find any
routes by the prefix table. routes by the prefix table.
There are also some other components defined in the LFB for various There are also some other components defined in the LFB for various
purposes. See section 6 for detailed XML definitions of the LFB. purposes. See section 6 for detailed XML definitions of the LFB.
5.3.2. IPv4NextHopApplicator 5.3.2. IPv4NextHop
This LFB abstracts the process of next hop information application to This LFB abstracts the process of next hop information application to
IPv4 packets. IPv4 packets.
The LFB receives an IPv4 packet with an associated next hop ID, and The LFB receives an IPv4 packet with an associated next hop ID, and
uses the ID to look up a next hop table to find an appropriate output uses the ID to look up a next hop table to find an appropriate output
port from the LFB. Simultaneously, the LFB also implements TTL port from the LFB. Simultaneously, the LFB also implements TTL
operation and checksum recalculation of every IPv4 packet received. operation and checksum recalculation of every IPv4 packet received.
Input of the LFB is a singleton one which expects to receive IPv4 Input of the LFB is a singleton one which expects to receive IPv4
skipping to change at page 46, line 14 skipping to change at page 51, line 14
5.3.3. IPv6UcastLPM 5.3.3. IPv6UcastLPM
The LFB abstracts the process for IPv6 unicast LPM table looking up. The LFB abstracts the process for IPv6 unicast LPM table looking up.
Definitions of this IPv6UcastLPM LFB is very identical to Definitions of this IPv6UcastLPM LFB is very identical to
IPv4UcastLPM LFB except that all IP addresses related are changed IPv4UcastLPM LFB except that all IP addresses related are changed
from IPv4 addresses to IPv6 addresses. See section 6 for detailed from IPv4 addresses to IPv6 addresses. See section 6 for detailed
XML definitions of this LFB. XML definitions of this LFB.
5.3.4. IPv6NextHopApplicator 5.3.4. IPv6NextHop
This LFB abstracts the process of next hop information application to This LFB abstracts the process of next hop information application to
IPv6 packets. IPv6 packets.
Definitions of this IPv6NextHopApplicator LFB is very identical to Definitions of this IPv6NextHop LFB is very identical to IPv4NextHop
IPv4NextHopApplicator LFB except that all IP addresses related are LFB except that all IP addresses related are changed from IPv4
changed from IPv4 addresses to IPv6 addresses. See section 6 for addresses to IPv6 addresses. See section 6 for detailed XML
detailed XML definitions of this LFB. definitions of this LFB.
5.4. Address Resolution LFBs 5.4. Address Resolution LFBs
The address resolution LFBs abstracts the process for address The address resolution LFBs abstracts the process for address
resolution functions. In the process, address resolution protocols, resolution functions. In the process, address resolution protocols,
like ARP protocol for IPv4 and neighbor discovery protocol for IPv6, like ARP protocol for IPv4 and neighbor discovery protocol for IPv6,
are applied. are applied.
There exist two schema under ForCES architecture to implement address There exist two schema under ForCES architecture to implement address
resolution function. One is for FE to implement the address resolution function. One is for FE to implement the address
skipping to change at page 53, line 8 skipping to change at page 58, line 8
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>PHYPortID</name> <name>PHYPortID</name>
<synopsis>The ID of the physical port that this LFB <synopsis>The ID of the physical port that this LFB
handles.</synopsis> handles.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2" access="read-write"> <component componentID="2" access="read-write">
<name>AdminStatus</name>
<synopsis>Admin Status of the LFB</synopsis>
<typeRef>PortStatusValues</typeRef>
<defaultValue>2</defaultValue>
</component>
<component componentID="3" access="read-only">
<name>OperStatus</name>
<synopsis>Operational Status of the LFB.</synopsis>
<typeRef>PortStatusValues</typeRef>
</component>
<component componentID="4" access="read-write">
<name>AdminLinkSpeed</name> <name>AdminLinkSpeed</name>
<synopsis>The link speed that the admin has requested. <synopsis>The link speed that the admin has requested.
</synopsis> </synopsis>
<typeRef>LANSpeedType</typeRef> <typeRef>LANSpeedType</typeRef>
<defaultValue>0x00000005</defaultValue> <defaultValue>0x00000005</defaultValue>
</component> </component>
<component componentID="3" access="read-only"> <component componentID="5" access="read-only">
<name>OperLinkSpeed</name> <name>OperLinkSpeed</name>
<synopsis>The actual operational link speed.</synopsis> <synopsis>The actual operational link speed.</synopsis>
<typeRef>LANSpeedType</typeRef> <typeRef>LANSpeedType</typeRef>
</component> </component>
<component componentID="4" access="read-write"> <component componentID="6" access="read-write">
<name>AdminDuplexMode</name> <name>AdminDuplexMode</name>
<synopsis>The duplex mode that the admin has requested. <synopsis>The duplex mode that the admin has requested.
</synopsis> </synopsis>
<typeRef>DuplexType</typeRef> <typeRef>DuplexType</typeRef>
<defaultValue>0x00000001</defaultValue> <defaultValue>0x00000001</defaultValue>
</component> </component>
<component componentID="5" access="read-only"> <component componentID="7" access="read-only">
<name>OperDuplexMode</name> <name>OperDuplexMode</name>
<synopsis>The actual duplex mode.</synopsis> <synopsis>The actual duplex mode.</synopsis>
<typeRef>DuplexType</typeRef> <typeRef>DuplexType</typeRef>
</component> </component>
<component componentID="6" access="read-write"> <component componentID="8" access="read-only">
<name>AdminStatus</name>
<synopsis>Status of the port</synopsis>
<typeRef>PortStatusValues</typeRef>
<defaultValue>2</defaultValue>
</component>
<component componentID="7" access="read-only">
<name>CarrierStatus</name> <name>CarrierStatus</name>
<synopsis>The status of the Carrier. Whether the port <synopsis>The status of the Carrier. Whether the port
is linked with an operational connector.</synopsis> is linked with an operational connector.</synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>0</defaultValue> <defaultValue>false</defaultValue>
</component>
<component componentID="8" access="read-reset">
<name>PHYPortStats</name>
<synopsis>Statistics of the Physical Port.</synopsis>
<typeRef>PHYPortStatsType</typeRef>
</component> </component>
</components> </components>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>SupportedLinkSpeed</name> <name>SupportedLinkSpeed</name>
<synopsis>Supported Link Speeds</synopsis> <synopsis>Supported Link Speeds</synopsis>
<array> <array>
<typeRef>LANSpeedType</typeRef> <typeRef>LANSpeedType</typeRef>
</array> </array>
</capability> </capability>
skipping to change at page 54, line 24 skipping to change at page 59, line 24
<typeRef>DuplexType</typeRef> <typeRef>DuplexType</typeRef>
</array> </array>
</capability> </capability>
</capabilities> </capabilities>
<events baseID="60"> <events baseID="60">
<event eventID="1"> <event eventID="1">
<name>PHYPortStatusChanged</name> <name>PHYPortStatusChanged</name>
<synopsis>When the status of the Physical port is <synopsis>When the status of the Physical port is
changed,the LFB sends the new status.</synopsis> changed,the LFB sends the new status.</synopsis>
<eventTarget> <eventTarget>
<eventField>AdminStatus</eventField> <eventField>OperStatus</eventField>
</eventTarget> </eventTarget>
<eventChanged/> <eventChanged/>
<eventReports> <eventReports>
<eventReport> <eventReport>
<eventField>AdminStatus</eventField> <eventField>OperStatus</eventField>
</eventReport> </eventReport>
</eventReports> </eventReports>
</event> </event>
<event eventID="2"> <event eventID="2">
<name>LinkSpeedChanged</name> <name>LinkSpeedChanged</name>
<synopsis>When the operational speed of the link <synopsis>When the operational speed of the link
is changed, the LFB sends the new operational link is changed, the LFB sends the new operational link
speed.</synopsis> speed.</synopsis>
<eventTarget> <eventTarget>
<eventField>OperLinkSpeed</eventField> <eventField>OperLinkSpeed</eventField>
</eventTarget> </eventTarget>
<eventChanged/> <eventChanged/>
<eventReports> <eventReports>
<eventReport> <eventReport>
<eventField>OperLinkSpeed</eventField> <eventField>OperLinkSpeed</eventField>
</eventReport> </eventReport>
</eventReports> </eventReports>
</event> </event>
<event eventID="3">
<name>DuplexModeChanged</name>
<synopsis>When the operational duplex mode
is changed, the LFB sends the new operational mode.
speed.</synopsis>
<eventTarget>
<eventField>OperDuplexMode</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperDuplexMode</eventField>
</eventReport>
</eventReports>
</event>
</events> </events>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="4"> <LFBClassDef LFBClassID="4">
<name>EtherMACIn</name> <name>EtherMACIn</name>
<synopsis>a LFB abstracts an Ethernet port at MAC data link <synopsis>a LFB abstracts an Ethernet port at MAC data link
layer. Multiple virtual MACs isn't supported in this LFB layer. Multiple virtual MACs isn't supported in this LFB
version.</synopsis> version.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
skipping to change at page 56, line 4 skipping to change at page 61, line 20
It can produce any kind of Ethernet frame and along It can produce any kind of Ethernet frame and along
with the frame passes the ID of the Physical Port as with the frame passes the ID of the Physical Port as
metadata to be used by the next LFBs.</synopsis> metadata to be used by the next LFBs.</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-only"> <component componentID="1" access="read-write">
<name>OperStatus</name> <name>AdminStatus</name>
<synopsis>Operational Status of the LFB.</synopsis> <synopsis>Admin Status of the port</synopsis>
<typeRef>PortStatusValues</typeRef> <typeRef>PortStatusValues</typeRef>
<defaultValue>2</defaultValue>
</component> </component>
<component componentID="2" access="read-write"> <component componentID="2" access="read-write">
<name>LocalMACAddresses</name> <name>LocalMACAddresses</name>
<synopsis>Local Mac Addresses</synopsis> <synopsis>Local Mac Addresses</synopsis>
<array> <array>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
</array> </array>
</component> </component>
<component componentID="3" access="read-write"> <component componentID="3" access="read-write">
<name>L2BridgingPathEnable</name> <name>L2BridgingPathEnable</name>
<synopsis>Is the LFB doing L2 Bridging?</synopsis> <synopsis>Is the LFB doing L2 Bridging?</synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="4" access="read-write"> <component componentID="4" access="read-write">
<name>PromiscuousMode</name> <name>PromiscuousMode</name>
<synopsis>Is the LFB in Promiscuous Mode?</synopsis> <synopsis>Is the LFB in Promiscuous Mode?</synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="5" access="read-only"> <component componentID="5" access="read-write">
<name>TxFlowControl</name> <name>TxFlowControl</name>
<synopsis>Transmit Flow control</synopsis> <synopsis>Transmit Flow control</synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="6" access="read-write"> <component componentID="6" access="read-write">
<name>RxFlowControl</name> <name>RxFlowControl</name>
<synopsis>Receive Flow control</synopsis> <synopsis>Receive Flow control</synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="7" access="read-write"> <component componentID="7" access="read-write">
<name>MTU</name> <name>MTU</name>
<synopsis>Maximum Transmission Unit</synopsis> <synopsis>Maximum Transmission Unit</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="8" access="read-reset"> <component componentID="8" access="read-reset">
<name>MACStats</name> <name>MACInStats</name>
<synopsis>MAC statistics</synopsis> <synopsis>MACIn statistics</synopsis>
<typeRef>MACStatsType</typeRef> <typeRef>MACInStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="5"> <LFBClassDef LFBClassID="5">
<name>EtherClassifier</name> <name>EtherClassifier</name>
<synopsis>LFB that decapsulates Ethernet II packets and <synopsis>LFB that decapsulates Ethernet II packets and
classifies them.</synopsis> classifies them.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>EtherPktsIn</name> <name>EtherPktsIn</name>
<synopsis>Input port for data packet.</synopsis> <synopsis>Input port for data packet.</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>EthernetAll</ref>
</frameExpected> </frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
<ref dependency="optional" defaultValue="0">
LogicalPortID</ref>
</metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="true">
<name>ClassifyOut</name> <name>ClassifyOut</name>
<synopsis>Classify Out</synopsis> <synopsis>Classify Out</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
skipping to change at page 57, line 31 skipping to change at page 63, line 4
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="true">
<name>ClassifyOut</name> <name>ClassifyOut</name>
<synopsis>Classify Out</synopsis> <synopsis>Classify Out</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameProduced> </frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
<ref>SrcMAC</ref>
<ref>DstMAC</ref>
<ref>EtherType</ref>
<ref availability="conditional">VlanID</ref>
<ref availability="conditional">VlanPriority</ref>
</metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component access="read-write" componentID="1"> <component access="read-write" componentID="1">
<name>EtherDispatchTable</name> <name>EtherDispatchTable</name>
<synopsis>Ether classify dispatch table</synopsis> <synopsis>Ether classify dispatch table</synopsis>
<array> <array>
<typeRef>EtherDispatchTableType</typeRef> <typeRef>EtherDispatchTableType</typeRef>
</array> </array>
</component> </component>
<component access="read-write" componentID="2"> <component access="read-write" componentID="2">
<name>VlanInputTable</name> <name>VlanInputTable</name>
<synopsis>Vlan input table</synopsis> <synopsis>Vlan input table</synopsis>
<array> <array>
<typeRef>VlanInputTableType</typeRef> <typeRef>VlanInputTableType</typeRef>
</array> </array>
</component> </component>
<component access="read-reset" componentID="3"> <component access="read-reset" componentID="3">
<name>EtherClassifyStats</name> <name>EtherClassifyStats</name>
<synopsis>Ether Classify statistic table</synopsis> <synopsis>Ether Classify statistic table</synopsis>
<array> <array>
<typeRef>EtherClassifyStatsType</typeRef> <typeRef>EtherClassifyStatsType</typeRef>
</array> </array>
</component> </component>
</components> </components>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>MaxOutPutPorts</name> <name>MaxOutputPorts</name>
<synopsis>Maximum number of ports in the output <synopsis>Maximum number of ports in the output
group.</synopsis> group.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="6"> <LFBClassDef LFBClassID="6">
<name>EtherEncapsulator</name> <name>EtherEncapsulator</name>
<synopsis>A LFB that performs packets ethernet L2 <synopsis>A LFB that performs packets ethernet L2
encapsulation.</synopsis> encapsulation.</synopsis>
skipping to change at page 59, line 23 skipping to change at page 65, line 4
<outputPort group="false"> <outputPort group="false">
<name>PakcetNoARPOut</name> <name>PakcetNoARPOut</name>
<synopsis>Output port for packets can't find the <synopsis>Output port for packets can't find the
associated L2 information in the ARP table.</synopsis> associated L2 information in the ARP table.</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>OutputLogicalPortID</ref> <ref>OutputLogicalPortID</ref>
<ref>NexthopIPAddr</ref> <ref>NexthopIPv4Addr</ref>
<ref availability="conditional">VlanPriority</ref> <ref availability="conditional">VlanPriority</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>PakcetNoNbrOut</name> <name>PakcetNoNbrOut</name>
<synopsis>Output port for packets can't find the <synopsis>Output port for packets can't find the
associated L2 information in the Nbr table.</synopsis> associated L2 information in the Nbr table.</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>OutputLogicalPortID</ref> <ref>OutputLogicalPortID</ref>
<ref>NexthopIPAddr</ref> <ref>NexthopIPv6Addr</ref>
<ref availability="conditional">VlanPriority</ref> <ref availability="conditional">VlanPriority</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis>All packets that fail with the other <synopsis>All packets that fail with the other
operations in this LFB are output via this port. operations in this LFB are output via this port.
</synopsis> </synopsis>
<product> <product>
skipping to change at page 60, line 4 skipping to change at page 65, line 33
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis>All packets that fail with the other <synopsis>All packets that fail with the other
operations in this LFB are output via this port. operations in this LFB are output via this port.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
<ref>OutputLogicalPortID</ref> <ref>OutputLogicalPortID</ref>
<ref>NexthopIPAddr</ref> <one-of>
<ref>NexthopIPv4Addr</ref>
<ref>NexthopIPv6Addr</ref>
</one-of>
<ref availability="conditional">VlanPriority</ref> <ref availability="conditional">VlanPriority</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>ArpTable</name> <name>ArpTable</name>
<synopsis>ARP table.</synopsis> <synopsis>ARP table.</synopsis>
<array type="variable-size"> <array type="variable-size">
skipping to change at page 60, line 50 skipping to change at page 66, line 34
<name>EtherMACOut</name> <name>EtherMACOut</name>
<synopsis>EtherMACOut LFB abstracts an Ethernet port at MAC <synopsis>EtherMACOut LFB abstracts an Ethernet port at MAC
data link layer. It specifically describes Ethernet packet data link layer. It specifically describes Ethernet packet
output process. Ethernet output functions are closely related output process. Ethernet output functions are closely related
to Ethernet input functions, therefore many components to Ethernet input functions, therefore many components
defined in this LFB are actually alias of EtherMACIn LFB. defined in this LFB are actually alias of EtherMACIn LFB.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>EtherPacketsIn</name> <name>EtherPktsIn</name>
<synopsis>The Input Port of the EtherMACIn. It expects <synopsis>The Input Port of the EtherMACIn. It expects
any kind of Ethernet frame.</synopsis> any kind of Ethernet frame.</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
skipping to change at page 61, line 37 skipping to change at page 67, line 21
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-only"> <component componentID="1" access="read-only">
<name>OperStatus</name> <name>OperStatus</name>
<synopsis>Operational Status of the LFB.</synopsis> <synopsis>Operational Status of the LFB.</synopsis>
<typeRef>PortStatusValues</typeRef> <typeRef>PortStatusValues</typeRef>
</component> </component>
<component componentID="2" access="read-only"> <component componentID="2" access="read-write">
<name>TxFlowControl</name> <name>TxFlowControl</name>
<synopsis>Transmit Flow control</synopsis> <synopsis>Transmit Flow control</synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="3" access="read-write"> <component componentID="3" access="read-write">
<name>RxFlowControl</name> <name>RxFlowControl</name>
<synopsis>Receive Flow control</synopsis> <synopsis>Receive Flow control</synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="4" access="read-reset"> <component componentID="4" access="read-reset">
<name>MACStats</name> <name>MACOutStats</name>
<synopsis>MAC statistics</synopsis> <synopsis>MACOut statistics</synopsis>
<typeRef>MACStatsType</typeRef> <typeRef>MACOutStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="8"> <LFBClassDef LFBClassID="8">
<name>IPv4Validator</name> <name>IPv4Validator</name>
<synopsis>a LFB that performs IPv4 packets validation <synopsis>a LFB that performs IPv4 packets validation
according to RFC1812 and RFC2644.</synopsis> according to RFC1812 and RFC2644.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>ValidatePktsIn</name> <name>ValidatePktsIn</name>
<synopsis>Input port for data packet.</synopsis> <synopsis>Input port for data packet.</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
skipping to change at page 63, line 4 skipping to change at page 68, line 37
</outputPort> </outputPort>
<outputPort> <outputPort>
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis>Output for exception packet.</synopsis> <synopsis>Output for exception packet.</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort> <outputPort>
<name>FailOutput</name> <name>FailOut</name>
<synopsis>Output for failed validation packet. <synopsis>Output for failed validation packet.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ValidateErrorID</ref> <ref>ValidateErrorID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
skipping to change at page 63, line 21 skipping to change at page 69, line 4
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ValidateErrorID</ref> <ref>ValidateErrorID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component access="read-write" componentID="1"> <component access="read-write" componentID="1">
<name>IPv4ValidatorStats</name> <name>IPv4ValidatorStats</name>
<synopsis>Ether classify dispatch table</synopsis> <synopsis>Ether classify dispatch table</synopsis>
<typeRef>IPv4ValidatorStatisticsType</typeRef> <typeRef>IPv4ValidatorStatisticsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="9"> <LFBClassDef LFBClassID="9">
<name>IPv6Validator</name> <name>IPv6Validator</name>
<synopsis>A LFB that performs IPv6 packets validation <synopsis>A LFB that performs IPv6 packets validation
according to RFC2460 and RFC4291.</synopsis> according to RFC2460 and RFC4291.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>ValidatePktsIn</name> <name>ValidatePktsIn</name>
<synopsis>Input port for data packet.</synopsis> <synopsis>Input port for data packet.</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
skipping to change at page 64, line 30 skipping to change at page 70, line 13
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort> <outputPort>
<name>FailOutput</name> <name>FailOut</name>
<synopsis>Output for failed validation packet. <synopsis>Output for failed validation packet.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ValidateErrorID</ref> <ref>ValidateErrorID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
skipping to change at page 65, line 9 skipping to change at page 70, line 41
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="10"> <LFBClassDef LFBClassID="10">
<name>IPv4UcastLPM </name> <name>IPv4UcastLPM </name>
<synopsis>a LFB that performs IPv4 Longest Prefix Match <synopsis>a LFB that performs IPv4 Longest Prefix Match
Lookup.</synopsis> Lookup.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PktIn</name> <name>PktsIn</name>
<synopsis>A Single Packet Input</synopsis> <synopsis>A Single Packet Input</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>DstIPv4Address</ref> <ref>DstIPv4Address</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
skipping to change at page 65, line 20 skipping to change at page 71, line 4
<synopsis>A Single Packet Input</synopsis> <synopsis>A Single Packet Input</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>DstIPv4Address</ref> <ref>DstIPv4Address</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="false"> <outputPort group="false">
<name>NormalOut</name> <name>NormalOut</name>
<synopsis>This output port is connected with <synopsis>This output port is connected with
IPv4NextHopApplicator LFB</synopsis> IPv4NextHop LFB</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>HopSelector</ref> <ref>HopSelector</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
skipping to change at page 66, line 37 skipping to change at page 72, line 22
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="11"> <LFBClassDef LFBClassID="11">
<name>IPv6UcastLPM </name> <name>IPv6UcastLPM </name>
<synopsis>A LFB that performs IPv6 Longest Prefix Match <synopsis>A LFB that performs IPv6 Longest Prefix Match
Lookup.</synopsis> Lookup.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PktIn</name> <name>PktsIn</name>
<synopsis>A Single Packet Input</synopsis> <synopsis>A Single Packet Input</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>DstIPv6Address</ref> <ref>DstIPv6Address</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="false"> <outputPort group="false">
<name>NormalOut</name> <name>NormalOut</name>
<synopsis>This output port is connected with <synopsis>This output port is connected with
IPv6NextHopApplicator LFB</synopsis> IPv6NextHop LFB</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>HopSelector</ref> <ref>HopSelector</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
skipping to change at page 68, line 11 skipping to change at page 73, line 43
</component> </component>
<component componentID="2" access="read-reset"> <component componentID="2" access="read-reset">
<name>IPv6UcastLPMStats</name> <name>IPv6UcastLPMStats</name>
<synopsis>Statistics for IPv6 Unicast Longest Prefix <synopsis>Statistics for IPv6 Unicast Longest Prefix
Match</synopsis> Match</synopsis>
<typeRef>IPv6UcastLPMStatsType</typeRef> <typeRef>IPv6UcastLPMStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="12"> <LFBClassDef LFBClassID="12">
<name>IPv4NextHopApplicator</name> <name>IPv4NextHop</name>
<synopsis>A LFB for applicating next hop action to IPv4 <synopsis>A LFB for applicating next hop action to IPv4
packets,the actions include:TTL operation,checksum packets,the actions include:TTL operation,checksum
recalculation. The input packets with the metadata recalculation. The input packets with the metadata
"HopSelector"(the nexthop ID), get the nexthop "HopSelector"(the nexthop ID), get the nexthop
information through looking up nexthop table.</synopsis> information through looking up nexthop table.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PktIn</name> <name>PktsIn</name>
<synopsis>A Single Packet Input</synopsis> <synopsis>A Single Packet Input</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>HopSelector</ref> <ref>HopSelector</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
skipping to change at page 69, line 20 skipping to change at page 75, line 4
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1"> <component componentID="1">
<name>IPv4NextHopTable</name> <name>IPv4NextHopTable</name>
<synopsis>The Next Hop Table.</synopsis> <synopsis>The Next Hop Table.</synopsis>
<array> <array>
<typeRef>IPv4NextHopTableType</typeRef> <typeRef>IPv4NextHopTableType</typeRef>
</array> </array>
</component> </component>
</components> </components>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>MaxOutPutPorts</name> <name>MaxOutputPorts</name>
<synopsis>Maximum number of ports in the output group. <synopsis>Maximum number of ports in the output group.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="13"> <LFBClassDef LFBClassID="13">
<name>IPv6NextHopApplicator</name> <name>IPv6NextHop</name>
<synopsis>A LFB definition for applicating next hop action to <synopsis>A LFB definition for applicating next hop action to
IPv6 packets,the actions include:TTL operation,checksum IPv6 packets. The input packets with the metadata
recalculation. The input packets with the metadata
"HopSelector"(the nexthop ID), get the nexthop information "HopSelector"(the nexthop ID), get the nexthop information
through looking up nexthop table.</synopsis> through looking up nexthop table.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PktIn</name> <name>PktsIn</name>
<synopsis>A Single Packet Input</synopsis> <synopsis>A Single Packet Input</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>HopSelector</ref> <ref>HopSelector</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
skipping to change at page 70, line 46 skipping to change at page 76, line 28
<component componentID="1"> <component componentID="1">
<name>IPv6NextHopTable</name> <name>IPv6NextHopTable</name>
<synopsis>The Next Hop Table.</synopsis> <synopsis>The Next Hop Table.</synopsis>
<array> <array>
<typeRef>IPv6NextHopTableType</typeRef> <typeRef>IPv6NextHopTableType</typeRef>
</array> </array>
</component> </component>
</components> </components>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>MaxOutPutPorts</name> <name>MaxOutputPorts</name>
<synopsis>Maximum number of ports in the output group. <synopsis>Maximum number of ports in the output group.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="14"> <LFBClassDef LFBClassID="14">
<name>ARP</name> <name>ARP</name>
<synopsis>ARP</synopsis> <synopsis>ARP</synopsis>
<version>1.0</version> <version>1.0</version>
skipping to change at page 71, line 21 skipping to change at page 77, line 4
<synopsis>The input port for ARP packets.</synopsis> <synopsis>The input port for ARP packets.</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>ARP</ref> <ref>ARP</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
<ref>LogicalPortID</ref> <ref>LogicalPortID</ref>
<ref>SrcMAC</ref> <ref>SrcMAC</ref>
<ref>DstMAC</ref> <ref>DstMAC</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
<inputPort group="false"> <inputPort group="false">
<name>AddrResDataPktIn</name> <name>AddrResDataPktsIn</name>
<synopsis>The input port for the packet which need <synopsis>The input port for the packet which need
address resolution..</synopsis> address resolution..</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv4</ref> <ref>IPv4</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>NexthopIPv4Addr</ref> <ref>NexthopIPv4Addr</ref>
<ref>OutputLogicalPortID</ref> <ref>OutputLogicalPortID</ref>
<ref dependency="optional" defaultValue="0"> <ref dependency="optional" defaultValue="0">
VlanID</ref> VlanID</ref>
<ref dependency="optional" defaultValue="0"> <ref dependency="optional" defaultValue="0">
VlanPriority</ref> VlanPriority</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="false"> <outputPort group="false">
<name>ArpOut</name> <name>ArpPktsOut</name>
<synopsis>The output port for Arp packets.</synopsis> <synopsis>The output port for Arp packets.</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>EthernetII</ref> <ref>EthernetII</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>OutputLogicalPortID</ref> <ref>OutputLogicalPortID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>AddrResDataPktOut</name> <name>AddrResDataPktsOut</name>
<synopsis>The output port for the packet which has been <synopsis>The output port for the packet which has been
encapsulated with the L2 head.</synopsis> encapsulated with the L2 head.</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>EthernetII</ref> <ref>EthernetII</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>OutputLogicalPortID</ref> <ref>OutputLogicalPortID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
skipping to change at page 73, line 17 skipping to change at page 78, line 49
LFB, the LFB will read the metadata and output the packet to LFB, the LFB will read the metadata and output the packet to
one of its group output port instance, whose port index is one of its group output port instance, whose port index is
just as indicated by the metadata.All metadata from CE other just as indicated by the metadata.All metadata from CE other
than the 'RedirectIndex' metadata will output from the than the 'RedirectIndex' metadata will output from the
RedirectIn LFB along with their binding packets. Note that, RedirectIn LFB along with their binding packets. Note that,
a packet without a 'RedirectIndex' metadata associated a packet without a 'RedirectIndex' metadata associated
will be dropped by the LFB.</synopsis> will be dropped by the LFB.</synopsis>
<version>1.0</version> <version>1.0</version>
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="true">
<name>PacketOut</name> <name>PktsOut</name>
<synopsis>This output group sends the redirected packet <synopsis>This output group sends the redirected packet
in the data path.</synopsis> in the data path.</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameProduced> </frameProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>MaxOutPutPorts</name> <name>MaxOutputPorts</name>
<synopsis>Maximum number of ports in the output group <synopsis>Maximum number of ports in the output group
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="17"> <LFBClassDef LFBClassID="17">
<name>RedirectOut</name> <name>RedirectOut</name>
<synopsis>A RedirectOut LFB abstracts the process for LFBs in <synopsis>A RedirectOut LFB abstracts the process for LFBs in
FE to deliver data packets to CE. From LFB topology point of FE to deliver data packets to CE. From LFB topology point of
skipping to change at page 74, line 6 skipping to change at page 79, line 37
capable of receiving packets from multiple LFBs by capable of receiving packets from multiple LFBs by
multiplexing the singleton input. Packets expected by the multiplexing the singleton input. Packets expected by the
input will have arbitrary frame types. All metadata input will have arbitrary frame types. All metadata
associated with the input packets will be delivered to CE associated with the input packets will be delivered to CE
via the redirect message of ForCES protocol [RFC5810], via the redirect message of ForCES protocol [RFC5810],
therefore the input will expect all types of metadata. therefore the input will expect all types of metadata.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PacketIn</name> <name>PktsIn</name>
<synopsis>This input group receives packets to send to <synopsis>This input group receives packets to send to
the CE.</synopsis> the CE.</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameExpected> </frameExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="18"> <LFBClassDef LFBClassID="18">
<name>BasicMetadataDispatch</name> <name>BasicMetadataDispatch</name>
<synopsis>This LFB provides the function to dispatch input <synopsis>This LFB provides the function to dispatch input
packets to a group output according to a metadata and a packets to a group output according to a metadata and a
dispatch table.</synopsis> dispatch table.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>PacketsIn</name> <name>PacketsIn</name>
<synopsis>Input port for data packet.</synopsis> <synopsis>Input port for data packet.</synopsis>
<expectation> <expectation>
skipping to change at page 75, line 9 skipping to change at page 80, line 40
</outputPorts> </outputPorts>
<components> <components>
<component access="read-write" componentID="1"> <component access="read-write" componentID="1">
<name>MetadataDispatchTable</name> <name>MetadataDispatchTable</name>
<synopsis>metadata dispatch table.</synopsis> <synopsis>metadata dispatch table.</synopsis>
<typeRef>MetadataDispatchTableType</typeRef> <typeRef>MetadataDispatchTableType</typeRef>
</component> </component>
</components> </components>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>MaxOutPutPorts</name> <name>MaxOutputPorts</name>
<synopsis>Maxium number of ports in the output group. <synopsis>Maxium number of ports in the output group.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="19"> <LFBClassDef LFBClassID="19">
<name>GenericScheduler</name> <name>GenericScheduler</name>
<synopsis>Generic Scheduler LFB.</synopsis> <synopsis>Generic Scheduler LFB.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="true"> <inputPort group="true">
<name>PacketsIn</name> <name>PacketsIn</name>
<synopsis>Input port for data packet.</synopsis> <synopsis>Input port for data packet.</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
skipping to change at page 77, line 5 skipping to change at page 83, line 5
</synopsis> </synopsis>
<array type="variable-size" maxLength="6"> <array type="variable-size" maxLength="6">
<typeRef>SchdDisciplineType</typeRef> <typeRef>SchdDisciplineType</typeRef>
</array> </array>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
</LFBClassDefs> </LFBClassDefs>
</LFBLibrary> </LFBLibrary>
7. Use Library for Typical Router Functions 7. LFB Class Use Cases
This section demonstrates examples on how the LFB classes defined by This section demonstrates examples on how the LFB classes defined by
the Base LFB library in Section 6 are applied to achieve typical the Base LFB library in Section 6 are applied to achieve typical
router functions. router functions.
As mentioned in the overview section, typical router functions can be As mentioned in the overview section, typical router functions can be
categorized in short into the following functions: categorized in short into the following functions:
o IP forwarding o IP forwarding
skipping to change at page 77, line 36 skipping to change at page 83, line 36
general, CE controls and manages the processing paths by use of the general, CE controls and manages the processing paths by use of the
ForCES protocol. ForCES protocol.
Note that LFB class use cases shown in this section are only as Note that LFB class use cases shown in this section are only as
examples to demonstrate how typical router functions can be examples to demonstrate how typical router functions can be
implemented with the defined base LFB library. Users and implemented with the defined base LFB library. Users and
implementers should not be limited by the examples. implementers should not be limited by the examples.
7.1. IP Forwarding 7.1. IP Forwarding
Figure 1 shows the typical LFB processing path for the IPv4 unicast TBD
forwarding case with Ethernet media interfaces.
+-----+ +------+
| | | |
| |<---------------|Ether |<----------------------------+
| | |MACOut| |
| | | | |
|Ether| +------+ |
|MAC | |
|Cop | +---+ |
|#1 | +-----+ | |----->IPv6 Packets |
| | | | | | +----+ |
| | |Ether| | | | | |
| |->|MACIn|-->| |IPv4| | |
+-----+ | | | |-+->| | +---+ |
+-----+ +--+ | | |unicast +-----+ | | |
Ether | | |------->| | | | |
. Classifier| | |packet |IPv4 | | | |
. | | | |Ucast|->| |--+ |
. | | | |LPM | | | | |
+---+ | +----+ +-----+ | | | |
+-----+ | | | IPv4 +---+ | |
| | | | | Validator IPv4 | |
+-----+ |Ether| | |-+ NextHop | |
| |->|MACIn|-->| |IPv4 Applicator| |
| | | | | |----->IPv6 Packets | |
|Ether| +-----+ +---+ +----+ | |
|MAC | Ether | | | |
|Cop | Classifier | | +-------+ | |
|#n | | | | | | |
| | +------+ | |<--| Ether |<-+ |
| | | |<------| | | Encap | |
| |<---------------|Ether | ...| | +-------+ |
| | |MACOut| +---| | |
| | | | | +----+ |
+-----+ +------+ | BasicMetadataDispatch |
+-------------------------+
Figure 1 IPv4 Forwarding case
Figure 2 shows the typical LFB processing path for the IPv6 unicast
forwarding case with media ports not considered.
Figure 2. (TBD)
7.2. Address Resolution 7.2. Address Resolution
TBD TBD
7.3. ICMP 7.3. ICMP
TBD TBD
7.4. Running Routing Protocol 7.4. Running Routing Protocol
TBD TBD
7.5. Network Management 7.5. Network Management
TBD TBD
8. Contributors 8. Contributors
The authors would like to thank Jamal Hadi Salim and Ligang Dong who The authors would like to thank Jamal Hadi Salim, Ligang Dong, and
made a major contribution to the development of this document. Fenggen Jia who made major contributions to the development of this
document.
Jamal Hadi Salim Jamal Hadi Salim
Mojatatu Networks Mojatatu Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@mojatatu.com Email: hadi@mojatatu.com
Ligang Dong Ligang Dong
Zhejiang Gongshang University Zhejiang Gongshang University
149 Jiaogong Road 149 Jiaogong Road
Hangzhou 310035 Hangzhou 310035
P.R.China P.R.China
Phone: +86-571-28877751 Phone: +86-571-28877751
EMail: donglg@mail.zjgsu.edu.cn EMail: donglg@mail.zjgsu.edu.cn
Fenggen Jia
National Digital Switching Center(NDSC)
Jianxue Road
Zhengzhou 452000
P.R.China
EMail: jfg@mail.ndsc.com.cn
9. Acknowledgements 9. Acknowledgements
This document is based on earlier documents from Joel Halpern, Ligang This document is based on earlier documents from Joel Halpern, Ligang
Dong, Fenggen Jia and Weiming Wang. Dong, Fenggen Jia and Weiming Wang.
10. IANA Considerations 10. IANA Considerations
(TBD) (TBD)
11. Security Considerations 11. Security Considerations
skipping to change at page 85, line 9 skipping to change at page 90, line 9
Framework", RFC 3746, April 2004. Framework", RFC 3746, April 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
Authors' Addresses Authors' Addresses
Weiming Wang Weiming Wang
Zhejiang Gongshang University Zhejiang Gongshang University
18, Xuezheng Str., Xiasha University Town 18 Xuezheng Str., Xiasha University Town
Hangzhou, 310018 Hangzhou, 310018
P.R.China P.R.China
Phone: +86-571-28877721 Phone: +86-571-28877721
Email: wmwang@zjgsu.edu.cn Email: wmwang@zjgsu.edu.cn
Evangelos Haleplidis Evangelos Haleplidis
University of Patras University of Patras
Patras, Patras,
Greece Greece
Email: ehalep@ece.upatras.gr Email: ehalep@ece.upatras.gr
Kentaro Ogawa Kentaro Ogawa
NTT Corporation NTT Corporation
Tokyo, Tokyo,
Japan Japan
Email: ogawa.kentaro@lab.ntt.co.jp Email: ogawa.kentaro@lab.ntt.co.jp
Fenggen Jia Chuanhuang Li
National Digital Switching Center(NDSC) Hangzhou BAUD Networks
Jianxue Road 408 Wen-San Road
Zhengzhou, 452000 Hangzhou, 310012
P.R.China P.R.China
Phone: +86-571-28877751 Phone: +86-571-28877751
Email: jfg@mail.ndsc.com.cn,fgjia@mail.zjgsu.edu.cn Email: chuanhuang_li@mail.zjgsu.edu.cn
Halpern Joel Halpern Joel
Ericsson Ericsson
P.O. Box 6049 P.O. Box 6049
Leesburg, 20178 Leesburg, 20178
VA VA
Phone: +1 703 371 3043 Phone: +1 703 371 3043
Email: joel.halpern@ericsson.com Email: joel.halpern@ericsson.com
 End of changes. 118 change blocks. 
356 lines changed or deleted 514 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/