draft-ietf-forces-lfb-lib-08.txt   draft-ietf-forces-lfb-lib-09.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: September 1, 2012 University of Patras Expires: November 23, 2012 University of Patras
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
C. Li C. Li
Hangzhou H3C Tech. Co., Ltd. Hangzhou H3C Tech. Co., Ltd.
J. Halpern J. Halpern
Ericsson Ericsson
February 29, 2012 May 22, 2012
ForCES Logical Function Block (LFB) Library ForCES Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-08 draft-ietf-forces-lfb-lib-09
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). The used in the Forwarding and Control Element Separation (ForCES). The
basic LFB classes are defined according to ForCES FE model and ForCES basic LFB classes are defined according to ForCES FE model and ForCES
protocol specifications, and are scoped to meet requirements of protocol specifications, and are scoped to meet requirements of
typical router functions and considered as the basic LFB library for typical router functions and considered as the basic LFB library for
ForCES. The library includes the descriptions of the LFBs and the ForCES. The library includes the descriptions of the LFBs and the
XML definitions. XML definitions.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 September 1, 2012. This Internet-Draft will expire on November 23, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Scope of the Library . . . . . . . . . . . . . . . . . . 8 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . 8
3.2. Overview of LFB Classes in the Library . . . . . . . . . 10 3.2. Overview of LFB Classes in the Library . . . . . . . . . 10
3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . 10 3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . 10
3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 10 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 11
3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12 3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12
3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13 3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13
4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. Compound Struct . . . . . . . . . . . . . . . . . . . 16 4.1.2. Compound Struct . . . . . . . . . . . . . . . . . . . 16
4.1.3. Compound Array . . . . . . . . . . . . . . . . . . . 16 4.1.3. Compound Array . . . . . . . . . . . . . . . . . . . 16
4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 17 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 17
4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 18 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 18
5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 43 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 43
5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43
5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44
5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46
5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 47 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 48
5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50
5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52
5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53
5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 53 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 53
5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55
5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 56 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 57
5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 57 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 57
5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59
5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61
5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63
5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65
5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66
5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67
5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 67 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 67
5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 68 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 69
6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 71 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 71
7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 100 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 101
7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 100 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 101
7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 101 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 102
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 105
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 106 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 107
10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 108 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 109
10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 108 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 109
10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 109 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 110
11. Security Considerations . . . . . . . . . . . . . . . . . . . 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 112
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
12.1. Normative References . . . . . . . . . . . . . . . . . . 112 12.1. Normative References . . . . . . . . . . . . . . . . . . 113
12.2. Informative References . . . . . . . . . . . . . . . . . 112 12.2. Informative References . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114
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
skipping to change at page 9, line 36 skipping to change at page 9, line 36
(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 in the same autonomous system. In addition, some
routers will need to support an exterior gateway protocol (EGP) routers will need to support an exterior gateway protocol (EGP)
to exchange topological information with other autonomous to exchange topological information with other autonomous
systems. For all routers, it is essential to provide ability to systems. For all routers, it is essential to provide ability to
manage static routing items. manage static routing items.
(6) Provide network management and system support facilities, (6) Provide network management and system support facilities,
including loading, debugging, status reporting, exception including loading, debugging, status reporting, statistcs query,
reporting and control. exception reporting and control.
The classical IP router utilizing the ForCES framework constitutes a The classical IP router utilizing the ForCES framework constitutes a
CE running some controlling IGP and/or EGP function or static route CE running some controlling IGP and/or EGP function or static route
setup and FEs implementing using Logical Function Blocks (LFBs) setup and FEs implementing using Logical Function Blocks (LFBs)
conforming to the FE model[RFC5812] specifications. The CE, in conforming to the FE model[RFC5812] specifications. The CE, in
conformance to the ForCES protocol[RFC5810] and the FE model conformance to the ForCES protocol[RFC5810] and the FE model
[RFC5812] specifications, instructs the LFBs on the FE how to treat [RFC5812] specifications, instructs the LFBs on the FE how to treat
received/sent packets. received/sent packets.
Packets in an IP router are received and transmitted on physical Packets in an IP router are received and transmitted on physical
skipping to change at page 10, line 37 skipping to change at page 10, line 37
3.2.1. LFB Design Choices 3.2.1. LFB Design Choices
A few design principles were factored into choosing how the base LFBs A few design principles were factored into choosing how the base LFBs
looked like. These are: looked like. These are:
o If a function can be designed by either one LFB or two or more o If a function can be designed by either one LFB or two or more
LFBs with the same cost, the choice is to go with two or more LFBs LFBs with the same cost, the choice is to go with two or more LFBs
so as to provide more flexibility for implementers. so as to provide more flexibility for implementers.
o When flexibility is not required, an LFB should take advantage of o An LFB should take advantage of its independence as much as
its independence as much as possible and have minimal coupling possible and have minimal coupling with other LFBs. The coupling
with other LFBs. The coupling may be from LFB attributes may be from LFB attributes definitions as well as physical
definitions as well as physical implementations. implementations.
o Unless there is a clear difference in functionality, similar o Unless there is a clear difference in functionality, similar
packet processing should not be represented as two or more packet processing in the base LFB library should not be
different LFBs. Or else, it may add extra burden on represented simultaneously as two or more LFBs. For instance, it
should not be simultaneously defined with two different LFBs for
the same next hop processing. Or else, it may add extra burden on
implementation to achieve interoperability. implementation to achieve interoperability.
3.2.2. LFB Class Groupings 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:
(1) 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 popular media type with rich processing features, Ethernet most popular media type with rich processing features, Ethernet
skipping to change at page 17, line 17 skipping to change at page 17, line 17
According to FE model [RFC5812], frame types are used in LFB According to FE model [RFC5812], frame types are used in LFB
definitions to define packet frame types both an LFB expects at its definitions to define packet frame types both an LFB expects at its
input port and the LFB emits at its output port. The <frameDef> input port and the LFB emits at its output port. The <frameDef>
element in the FE model is used to define a new frame type. element in the FE model is used to define a new frame type.
The following frame types are defined in the base type library: The following frame types are defined in the base type library:
Frame Name Brief Description Frame Name Brief Description
-------------- ---------------- -------------- ----------------
EthernetII An Ethernet II frame EthernetII An Ethernet II frame
ARP An ARP packet ARP An ARP packet frame
IPv4 An IPv4 packet IPv4 An IPv4 packet frame
IPv6 An IPv6 packet IPv6 An IPv6 packet frame
IPv4Unicast An IPv4 unicast packet IPv4Unicast An IPv4 unicast packet frame
IPv4Multicast An IPv4 multicast packet IPv4Multicast An IPv4 multicast packet frame
IPv6Unicast An IPv6 unicast packet IPv6Unicast An IPv6 unicast packet frame
IPv6Multicast An IPv6 multicast packet IPv6Multicast An IPv6 multicast packet frame
Arbitrary Any type of packet frames Arbitrary Any type of packet frames
4.3. MetaData Types 4.3. MetaData Types
LFB Metadata is used to communicate per-packet state from one LFB to LFB Metadata is used to communicate per-packet state from one LFB to
another. The <metadataDef> element in the FE model is used to define another. The <metadataDef> element in the FE model is used to define
a new metadata type. a new metadata type.
The following metadata types are currently defined in the base type The following metadata types are currently defined in the base type
library. library.
skipping to change at page 21, line 18 skipping to change at page 21, line 18
<dataTypeDef> <dataTypeDef>
<name>PortStatusType</name> <name>PortStatusType</name>
<synopsis> <synopsis>
Data types for port status, used for both administrative and Data types for port status, used for both administrative and
operative status. operative status.
</synopsis> </synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>Disabled </name> <name>Disabled</name>
<synopsis>Port is operatively disabled</synopsis> <synopsis>Port is operatively disabled</synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>Up</name> <name>Up</name>
<synopsis>Port is up</synopsis> <synopsis>Port is up</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>Down</name> <name>Down</name>
<synopsis>Port is down</synopsis> <synopsis>Port is down</synopsis>
</specialValue> </specialValue>
skipping to change at page 22, line 23 skipping to change at page 22, line 23
<name>NumPacketsDropped</name> <name>NumPacketsDropped</name>
<synopsis>Number of packets dropped</synopsis> <synopsis>Number of packets dropped</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherDispatchEntryType</name> <name>EtherDispatchEntryType</name>
<synopsis> <synopsis>
Data type for entry of Ethernet dispatch table in Data type for entry of Ethernet dispatch table in
EtherClassifier LFB. EtherClassifier LFB
</synopsis> </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>
<synopsis> <synopsis>
skipping to change at page 23, line 37 skipping to change at page 23, line 37
<baseType>uchar</baseType> <baseType>uchar</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="0" max="7"/> <allowedRange min="0" max="7"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>VlanInputTableEntryType</name> <name>VlanInputTableEntryType</name>
<synopsis> <synopsis>
Data type for entry of VLAN input table in EtherClassifier Data type for entry of VLAN input table in EtherClassifier
LFB. LFB
</synopsis> </synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IncomingPortID</name> <name>IncomingPortID</name>
<synopsis>The incoming port ID</synopsis> <synopsis>The incoming port ID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>VlanID</name> <name>VlanID</name>
<synopsis>The VLAN ID</synopsis> <synopsis>The VLAN ID</synopsis>
skipping to change at page 24, line 37 skipping to change at page 24, line 37
Ethernet type in the Ethernet packet header. Ethernet type in the Ethernet packet header.
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>VlanInputTableEntryType</typeRef> <typeRef>VlanInputTableEntryType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherClassifyStatsType</name> <name>EtherClassifyStatsType</name>
<synopsis> <synopsis>
Data type for entry of statistics table in EtherClassifier Data type for entry of statistics table in EtherClassifier
LFB. LFB
</synopsis> </synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>EtherType</name> <name>EtherType</name>
<synopsis> <synopsis>
The Ethernet type as defined in Ethernet packet header The Ethernet type as defined in Ethernet packet header
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
skipping to change at page 46, line 49 skipping to change at page 46, line 49
bridging LFB instances following the L2BridgingPathOut, FEs are bridging LFB instances following the L2BridgingPathOut, FEs are
expected to fulfill L2 bridging functions. L2BridgingPathOut will expected to fulfill L2 bridging functions. L2BridgingPathOut will
output packets exactly the same as that in the NormalPathOut output. output packets exactly the same as that in the NormalPathOut output.
This LFB can be set to work in a Promiscuous Mode, allowing all This LFB can be set to work in a Promiscuous Mode, allowing all
packets to pass through the LFB without being dropped. Otherwise, a packets to pass through the LFB without being dropped. Otherwise, a
locality check will be performed based on the local MAC addresses. locality check will be performed based on the local MAC addresses.
All packets that do not pass through the locality check will be All packets that do not pass through the locality check will be
dropped. dropped.
This LFB participates in Ethernet flow control in cooperation with This LFB can optionally participate in Ethernet flow control in
EtherMACOut LFB. This document does not go into the details of how cooperation with EtherMACOut LFB. This document does not go into the
this is implemented; the reader may refer to some relevant details of how this is implemented; the reader may refer to some
references. This document also does not describe how the buffers relevant references. This document also does not describe how the
which induce the flow control messages behave - it is assumed that buffers which induce the flow control messages behave - it is assumed
such artifacts exist and describing them is out of scope in this that such artifacts exist and describing them is out of scope in this
document. document.
5.1.2.2. Components 5.1.2.2. Components
The AdminStatus component is defined for the CE to administratively The AdminStatus component is defined for the CE to administratively
manage the status of the LFB. The CE may administratively startup or manage the status of the LFB. The CE may administratively startup or
shutdown the LFB by changing the value of AdminStatus. The default shutdown the LFB by changing the value of AdminStatus. The default
value is set to 'Down'. value is set to 'Down'.
The LocalMACAddresses component specifies the local MAC addresses The LocalMACAddresses component specifies the local MAC addresses
skipping to change at page 47, line 30 skipping to change at page 47, line 30
An L2BridgingPathEnable component captures whether the LFB is set to An L2BridgingPathEnable component captures whether the LFB is set to
work as a L2 bridge. An FE that does not support bridging will work as a L2 bridge. An FE that does not support bridging will
internally set this flag to false, and additionally set the flag internally set this flag to false, and additionally set the flag
property as read-only. The default value for is 'false'. property as read-only. The default value for is 'false'.
The PromiscuousMode component specifies whether the LFB is set to The PromiscuousMode component specifies whether the LFB is set to
work as in a promiscuous mode. The default value for is 'false'. work as in a promiscuous mode. The default value for is 'false'.
The TxFlowControl component defines whether the LFB is performing The TxFlowControl component defines whether the LFB is performing
flow control on sending packets. The default value for is 'false'. flow control on sending packets. The default value for is 'false'.
Note that the component is defined as "optional". If an FE does not
implement the component while a CE try to configure the component to
this FE, an error from FE may be responded to CE with error code
like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or 0x15(E_NOT_SUPPORTED)
depending on the FE processing. See [RFC5810] for details.
The RxFlowControl component defines whether the LFB is performing The RxFlowControl component defines whether the LFB is performing
flow control on receiving packets. The default value for is 'false'. flow control on receiving packets. The default value for is
'false'.The component is also defined as "optional" one.
A struct component, MACInStats, defines a set of statistics for this A struct component, MACInStats, defines a set of statistics for this
LFB, including the number of received packets and the number of LFB, including the number of received packets and the number of
dropped packets. dropped packets. Note that this statistics component is optional to
implementers. If a CE tries to query the componennt while it is not
implemented in an FE, an error code will be responded to CE
indicating the error type like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or
0x15(E_NOT_SUPPORTED), depending on the FE implementation.
5.1.2.3. Capabilities 5.1.2.3. Capabilities
This LFB does not have a list of capabilities. This LFB does not have a list of capabilities.
5.1.2.4. Events 5.1.2.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.1.3. EtherClassifier 5.1.3. EtherClassifier
skipping to change at page 49, line 45 skipping to change at page 50, line 5
Note that the logical port ID and physical port ID mentioned above Note that the logical port ID and physical port ID mentioned above
are all originally configured by CE, and are globally effective are all originally configured by CE, and are globally effective
within a ForCES NE (Network Element). To distinguish a physical port within a ForCES NE (Network Element). To distinguish a physical port
ID from a logical port ID in the incoming port ID field of the ID from a logical port ID in the incoming port ID field of the
VlanInputTable, physical port ID and logical port ID must be assigned VlanInputTable, physical port ID and logical port ID must be assigned
with separate number spaces. with separate number spaces.
An array component, EtherClassifyStats, defines a set of statistics An array component, EtherClassifyStats, defines a set of statistics
for this LFB, measuring the number of packets per EtherType. Each for this LFB, measuring the number of packets per EtherType. Each
row of the array is a struct containing an EtherType and a Packet row of the array is a struct containing an EtherType and a Packet
number. number.Note that this statistics component is optional to
implementers.
5.1.3.3. Capabilities 5.1.3.3. Capabilities
This LFB does not have a list of capabilities. This LFB does not have a list of capabilities.
5.1.3.4. Events 5.1.3.4. Events
This LFB has no events specified. This LFB has no events specified.
5.1.4. EtherEncap 5.1.4. EtherEncap
skipping to change at page 50, line 23 skipping to change at page 50, line 30
5.1.4.1. Data Handling 5.1.4.1. Data Handling
This LFB abstracts the process of encapsulating Ethernet headers onto This LFB abstracts the process of encapsulating Ethernet headers onto
received packets. The encapsulation is based on passed metadata. received packets. The encapsulation is based on passed metadata.
The LFB is expected to receive IPv4 and IPv6 packets, via a singleton The LFB is expected to receive IPv4 and IPv6 packets, via a singleton
input port known as "EncapIn" which may be connected to an upstream input port known as "EncapIn" which may be connected to an upstream
LFB like an IPv4NextHop, an IPv6NextHop, BasicMetadataDispatch, or LFB like an IPv4NextHop, an IPv6NextHop, BasicMetadataDispatch, or
any LFB which requires to output packets for Ethernet encapsulation. any LFB which requires to output packets for Ethernet encapsulation.
The LFB always expects from upstream LFBs the The LFB always expects from upstream LFBs the MediaEncapInfoIndex
MedTableiaEncapInfoIndex metadata which is used as a search key to metadata which is used as a search key to lookup the encapsulation
lookup the encapsulation table EncapTable by the search key matching table EncapTable by the search key matching the table index. An
the table index. An input packet may also optionally receive a VLAN input packet may also optionally receive a VLAN priority metadata,
priority metadata, indicating that the packet is originally with a indicating that the packet is originally with a priority value. The
priority value. The priority value will be loaded back to the packet priority value will be loaded back to the packet when encapsulating.
when encapsulating. The optional VLAN priority metadata is defined The optional VLAN priority metadata is defined with a default value
with a default value 0. 0.
Two singleton output LFB ports are defined. Two singleton output LFB ports are defined.
The first singleton output known as "SuccessOut". Upon a successful The first singleton output known as "SuccessOut". Upon a successful
table lookup, the destination and source MAC addresses, and the table lookup, the destination and source MAC addresses, and the
logical media port (L2PortID) are found in the matching table entry. logical media port (L2PortID) are found in the matching table entry.
The CE may set the VlanID in case VLANs are used. By default the The CE may set the VlanID in case VLANs are used. By default the
table entry for VlanID of 0 is used as per IEEE rules. Whatever the table entry for VlanID of 0 is used as per IEEE rules. Whatever the
value of VlanID is, if the input metadata VlanPriority is non-zero, value of VlanID is, if the input metadata VlanPriority is non-zero,
the packet will have a VLAN tag. If the VlanPriority and the VlanID the packet will have a VLAN tag. If the VlanPriority and the VlanID
skipping to change at page 52, line 30 skipping to change at page 52, line 34
singleton input known as "EtherPktsIn", which are usually output from singleton input known as "EtherPktsIn", which are usually output from
an Ethernet encapsulation LFB, alongside with a metadata indicating an Ethernet encapsulation LFB, alongside with a metadata indicating
the physical port ID that the packet will go through. the physical port ID that the packet will go through.
The LFB is defined with a singleton output. All Output packets are The LFB is defined with a singleton output. All Output packets are
in Ethernet format, possibly with various Ethernet types, alongside in Ethernet format, possibly with various Ethernet types, alongside
with a metadata indicating the physical port ID the packet is to go with a metadata indicating the physical port ID the packet is to go
through. This output links to a downstream LFB that is usually an through. This output links to a downstream LFB that is usually an
Ethernet physical LFB like EtherPHYcop LFB. Ethernet physical LFB like EtherPHYcop LFB.
This LFB participates in Ethernet flow control in cooperation with This LFB can optionally participate in Ethernet flow control in
EtherMACIn LFB. This document does not go into the details of how cooperation with EtherMACIn LFB. This document does not go into the
this is implemented; the reader may refer to some relevant details of how this is implemented; the reader may refer to some
references. This document also does not describe how the buffers relevant references. This document also does not describe how the
which induce the flow control messages behave - it is assumed that buffers which induce the flow control messages behave - it is assumed
such artifacts exist and describing them is out of scope in this that such artifacts exist and describing them is out of scope in this
document. document.
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.
5.1.5.2. Components 5.1.5.2. Components
The AdminStatus component is defined for CE to administratively The AdminStatus component is defined for CE to administratively
manage the status of the LFB. The CE may administratively startup or manage the status of the LFB. The CE may administratively startup or
skipping to change at page 53, line 9 skipping to change at page 53, line 13
alias of the AdminStatus component in the EtherMACIn LFB. This alias of the AdminStatus component in the EtherMACIn LFB. This
infers that an EtherMACOut LFB usually coexists with an EtherMACIn infers that an EtherMACOut LFB usually coexists with an EtherMACIn
LFB, both of which share the same administrative status management by LFB, both of which share the same administrative status management by
CE. Alias properties as defined in the ForCES FE model [RFC5812] CE. Alias properties as defined in the ForCES FE model [RFC5812]
will be used by CE to declare the target component this alias refers, will be used by CE to declare the target component this alias refers,
which include the target LFB class and instance IDs as well as the which include the target LFB class and instance IDs as well as the
path to the target component. path to the target component.
The MTU component defines the maximum transmission unit. The MTU component defines the maximum transmission unit.
The TxFlowControl component defines whether the LFB is performing The optinal TxFlowControl component defines whether the LFB is
flow control on sending packets. The default value for is 'false'. performing flow control on sending packets. The default value for is
Note that this component is defined as an alias of TxFlowControl 'false'. Note that this component is defined as an alias of
component in the EtherMACIn LFB. TxFlowControl component in the EtherMACIn LFB.
The RxFlowControl component defines whether the LFB is performing The optional RxFlowControl component defines whether the LFB is
flow control on receiving packets. The default value for is 'false'. performing flow control on receiving packets. The default value for
Note that this component is defined as an alias of RxFlowControl is 'false'. Note that this component is defined as an alias of
component in the EtherMACIn LFB. RxFlowControl component in the EtherMACIn LFB.
A struct component, MACOutStats, defines a set of statistics for this A struct component, MACOutStats, defines a set of statistics for this
LFB, including the number of transmitted packets and the number of LFB, including the number of transmitted packets and the number of
dropped packets. dropped packets. This statistics component is optional to
impleneters.
5.1.5.3. Capabilities 5.1.5.3. Capabilities
This LFB does not have a list of capabilities. This LFB does not have a list of capabilities.
5.1.5.4. Events 5.1.5.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.2. IP Packet Validation LFBs 5.2. IP Packet Validation LFBs
skipping to change at page 54, line 45 skipping to change at page 55, line 4
error case is the case when a packet is unable to be further error case is the case when a packet is unable to be further
processed nor forwarded except being dropped. An error ID is processed nor forwarded except being dropped. An error ID is
associated a packet to indicate the failure reason. Currently associated a packet to indicate the failure reason. Currently
defined failure reasons include: defined failure reasons include:
o Packet with size reported less than 20 bytes o Packet with size reported less than 20 bytes
o Packet with version is not IPv4 o Packet with version is not IPv4
o Packet with header length less than 5 words o Packet with header length less than 5 words
o Packet with total length field less than 20 bytes o Packet with total length field less than 20 bytes
o Packet with invalid checksum o Packet with invalid checksum
o Packet with invalid source address o Packet with invalid source address
o Packet with invalid destination address o Packet with invalid destination address
5.2.1.2. Components 5.2.1.2. Components
This LFB has only one struct component, the This LFB has only one struct component, the
IPv4ValidatorStatisticsType, which defines a set of statistics for IPv4ValidatorStatisticsType, which defines a set of statistics for
validation process, including the number of bad header packets, the validation process, including the number of bad header packets, the
number of bad total length packets, the number of bad TTL packets, number of bad total length packets, the number of bad TTL packets,
and the number of bad checksum packets. and the number of bad checksum packets. This statistics componennt
is optional to implementers.
5.2.1.3. Capabilities 5.2.1.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities
5.2.1.4. Events 5.2.1.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.2.2. IPv6Validator 5.2.2. IPv6Validator
skipping to change at page 56, line 39 skipping to change at page 56, line 45
validate error ID metadata are applied to both IPv4Validator and validate error ID metadata are applied to both IPv4Validator and
IPv6Validator LFBs, i.e., the two LFBs share the same medadata IPv6Validator LFBs, i.e., the two LFBs share the same medadata
definition, with different ID assignment inside. definition, with different ID assignment inside.
5.2.2.2. Components 5.2.2.2. Components
This LFB has only one struct component, the This LFB has only one struct component, the
IPv6ValidatorStatisticsType, which defines a set of statistics for IPv6ValidatorStatisticsType, which defines a set of statistics for
validation process, including the number of bad header packets, the validation process, including the number of bad header packets, the
number of bad total length packets, and the number of bad hop limit number of bad total length packets, and the number of bad hop limit
packets. packets. Note that this component is optional to implementers.
5.2.2.3. Capabilities 5.2.2.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities
5.2.2.4. Events 5.2.2.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.3. IP Forwarding LFBs 5.3. IP Forwarding LFBs
skipping to change at page 59, line 10 skipping to change at page 59, line 20
LFB. Each row of the array contains an IPv4 address, a Prefix LFB. Each row of the array contains an IPv4 address, a Prefix
length, a Hop Selector, an ECMP flag and a Default Route flag. The length, a Hop Selector, an ECMP flag and a Default Route flag. The
LFB uses the destination IPv4 address of every input packet as search LFB uses the destination IPv4 address of every input packet as search
key to look up this table in order extract a next hop selector. The key to look up this table in order extract a next hop selector. The
ECMP flag is for the LFB to support ECMP. The default route flag is ECMP flag is for the LFB to support ECMP. The default route flag is
for the LFB to support a default route and for loose RPF. for the LFB to support a default route and for loose RPF.
The IPv4UcastLPMStats component is a struct component which collects The IPv4UcastLPMStats component is a struct component which collects
statistics information, including the total number of input packets statistics information, including the total number of input packets
received, the IPv4 packets forwarded by this LFB and the number of IP received, the IPv4 packets forwarded by this LFB and the number of IP
datagrams discarded due to no route found. datagrams discarded due to no route found.Note the component is
defined as optional to implementers.
5.3.1.3. Capabilities 5.3.1.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities
5.3.1.4. Events 5.3.1.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.3.2. IPv4NextHop 5.3.2. IPv4NextHop
skipping to change at page 63, line 8 skipping to change at page 63, line 19
The IPv6PrefixTable component is defined as an array component of the The IPv6PrefixTable component is defined as an array component of the
LFB. Each row of the array contains an IPv6 address, a Prefix LFB. Each row of the array contains an IPv6 address, a Prefix
length, a Hop Selector, an ECMP flag and a Default Route flag. The length, a Hop Selector, an ECMP flag and a Default Route flag. The
ECMP flag is so the LFB can support ECMP. The default route flag is ECMP flag is so the LFB can support ECMP. The default route flag is
for the LFB to support a default route and for loose RPF as described for the LFB to support a default route and for loose RPF as described
earlier. earlier.
The IPv6UcastLPMStats component is a struct component which collects The IPv6UcastLPMStats component is a struct component which collects
statistics information, including the total number of input packets statistics information, including the total number of input packets
received, the IPv6 packets forwarded by this LFB and the number of IP received, the IPv6 packets forwarded by this LFB and the number of IP
datagrams discarded due to no route found. datagrams discarded due to no route found.Note the component is
defined as optional to implementers.
5.3.3.3. Capabilities 5.3.3.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities
5.3.3.4. Events 5.3.3.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.3.4. IPv6NextHop 5.3.4. IPv6NextHop
skipping to change at page 66, line 14 skipping to change at page 66, line 25
'RedirectIndex' metadata, which is an integer acting as an index. 'RedirectIndex' metadata, which is an integer acting as an index.
When the CE transmits the metadata along with the packet to a When the CE transmits the metadata along with the packet to a
RedirectIn LFB, the LFB will read the RedirectIndex metadata and RedirectIn LFB, the LFB will read the RedirectIndex metadata and
output the packet to one of its group output port instance, whose output the packet to one of its group output port instance, whose
port index is indicated by this metadata. Any other metadata, in port index is indicated by this metadata. Any other metadata, in
addition to 'RedirectIndex', will be passed untouched along the addition to 'RedirectIndex', will be passed untouched along the
packet delivered by the CE to downstream LFB. This means the packet delivered by the CE to downstream LFB. This means the
'RedirectIndex' metadata from CE will be "consumed" by the RedirectIn 'RedirectIndex' metadata from CE will be "consumed" by the RedirectIn
LFB and will not be passed to downstream LFB. Note that, a packet LFB and will not be passed to downstream LFB. Note that, a packet
from CE without a 'RedirectIndex' metadata associated will be dropped from CE without a 'RedirectIndex' metadata associated will be dropped
by the LFB. by the LFB. Note that all metadata visible to the LFB need to be
global and IANA controlled. See the "IANA Considerations" of the
document for more details, where a metadata ID private space that can
be used by vendors is also provided.
5.4.1.2. Components 5.4.1.2. Components
There are no components defined for the current version of RedirectIn An optional statistics component is defined to collect the number of
LFB. packets received by the LFB from CE. There are no other components
defined for current version of the LFB.
5.4.1.3. Capabilities 5.4.1.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities
5.4.1.4. Events 5.4.1.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.4.2. RedirectOut 5.4.2. RedirectOut
skipping to change at page 67, line 7 skipping to change at page 67, line 26
therefore the frame type has been specified as arbitrary, and also therefore the frame type has been specified as arbitrary, and also
all types of metadata are expected. All associated metadata produced all types of metadata are expected. All associated metadata produced
(but not consumed) by previous processed LFBs should be delivered to (but not consumed) by previous processed LFBs should be delivered to
CE via the ForCES protocol redirect message [RFC5810]. The CE can CE via the ForCES protocol redirect message [RFC5810]. The CE can
decide on how to process the redirected packet by referencing the decide on how to process the redirected packet by referencing the
associated metadata. As an example, a packet could be redirected by associated metadata. As an example, a packet could be redirected by
the FE to the CE because the EtherEncap LFB is not able to resolve L2 the FE to the CE because the EtherEncap LFB is not able to resolve L2
information. The metadata "ExceptionID", created by the EtherEncap information. The metadata "ExceptionID", created by the EtherEncap
LFB is passed along with the packet and should be sufficient for the LFB is passed along with the packet and should be sufficient for the
CE to do the necessary processing and resolve the L2 entry required. CE to do the necessary processing and resolve the L2 entry required.
Note that all metadata visible to the LFB need to be global and IANA
controlled. See the "IANA Considerations" of the document for more
details, where a metadata ID private space that can be used by
vendors is also provided.
5.4.2.2. Components 5.4.2.2. Components
There are no components defined for the current version of An optional statistics component is defined to collect the number of
RedirectOut LFB. packets sent by the LFB to CE. There are no other components defined
for current version of the LFB.
5.4.2.3. Capabilities 5.4.2.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities
5.4.2.4. Events 5.4.2.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.5. General Purpose LFBs 5.5. General Purpose LFBs
skipping to change at page 69, line 48 skipping to change at page 70, line 20
The SchedulingDiscipline component is for the CE to specify a The SchedulingDiscipline component is for the CE to specify a
scheduling discipline to the LFB. Currently defined scheduling scheduling discipline to the LFB. Currently defined scheduling
disciplines only include Round Robin (RR) strategy. The default disciplines only include Round Robin (RR) strategy. The default
scheduling discipline is RR then. scheduling discipline is RR then.
The QueueStats component is defined to allow CE to query every queue The QueueStats component is defined to allow CE to query every queue
status of the scheduler. It is an array component and each row of status of the scheduler. It is an array component and each row of
the array is a struct containing a queue ID. Currently defined queue the array is a struct containing a queue ID. Currently defined queue
status includes the queue depth in packets and the queue depth in status includes the queue depth in packets and the queue depth in
bytes. Using the queue ID as the index, the CE can query every queue bytes. Using the queue ID as the index, the CE can query every queue
for its used length in unit of packets or bytes. for its used length in unit of packets or bytes.Note that the
QueueStats componennt is defined as optional to implementers.
5.5.2.3. Capabilities 5.5.2.3. Capabilities
The following capability is currently defined for the The following capability is currently defined for the
GenericScheduler. GenericScheduler.
o The queue length limit providing the storage ability for every o The queue length limit providing the storage ability for every
queue. queue.
5.5.2.4. Events 5.5.2.4. Events
skipping to change at page 77, line 6 skipping to change at page 77, line 6
</synopsis> </synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="5" access="read-write"> <component componentID="5" access="read-write">
<name>TxFlowControl</name> <name>TxFlowControl</name>
<synopsis> <synopsis>
A flag indicating whether transmit flow control is A flag indicating whether transmit flow control is
applied or not. Default is not. applied or not. Default is not.
</synopsis> </synopsis>
<optional/>
<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> <synopsis>
A flag indicating whether receive flow control is A flag indicating whether receive flow control is
applied or not. Default is not. applied or not. Default is not.
</synopsis> </synopsis>
<optional/>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="7" access="read-reset"> <component componentID="7" access="read-reset">
<name>MACInStats</name> <name>MACInStats</name>
<synopsis> <synopsis>
The statistics of the EtherMACIn LFB The statistics of the EtherMACIn LFB
</synopsis> </synopsis>
<optional/>
<typeRef>MACInStatsType</typeRef> <typeRef>MACInStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="5"> <LFBClassDef LFBClassID="5">
<name>EtherClassifier</name> <name>EtherClassifier</name>
<synopsis> <synopsis>
EtherClassifier LFB abstracts the process to decapsulate EtherClassifier LFB abstracts the process to decapsulate
Ethernet packets and then classifies them into various Ethernet packets and then classifies them into various
network layer packets according to information in the network layer packets according to information in the
skipping to change at page 79, line 27 skipping to change at page 79, line 30
to the packet incoming port ID and the VLAN ID. to the packet incoming port ID and the VLAN ID.
</synopsis> </synopsis>
<typeRef>VlanInputTableType</typeRef> <typeRef>VlanInputTableType</typeRef>
</component> </component>
<component access="read-reset" componentID="3"> <component access="read-reset" componentID="3">
<name>EtherClassifyStats</name> <name>EtherClassifyStats</name>
<synopsis> <synopsis>
A table records statistics on the Ethernet A table records statistics on the Ethernet
classifying process in the LFB. classifying process in the LFB.
</synopsis> </synopsis>
<optional/>
<typeRef>EtherClassifyStatsTableType</typeRef> <typeRef>EtherClassifyStatsTableType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="6"> <LFBClassDef LFBClassID="6">
<name>EtherEncap</name> <name>EtherEncap</name>
<synopsis> <synopsis>
This LFB abstracts the process of encapsulating Ethernet This LFB abstracts the process of encapsulating Ethernet
headers onto received packets. The encapsulation is based headers onto received packets. The encapsulation is based
on passed metadata. on passed metadata.
skipping to change at page 82, line 38 skipping to change at page 82, line 42
<synopsis>Maximum transmission unit (MTU) </synopsis> <synopsis>Maximum transmission unit (MTU) </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3" access="read-write"> <component componentID="3" access="read-write">
<name>TxFlowControl</name> <name>TxFlowControl</name>
<synopsis> <synopsis>
A flag indicating whether transmit flow control is A flag indicating whether transmit flow control is
applied, defined as alias of TxFlowControl component applied, defined as alias of TxFlowControl component
in EtherMACIn LFB. in EtherMACIn LFB.
</synopsis> </synopsis>
<optional/>
<alias>boolean</alias> <alias>boolean</alias>
</component> </component>
<component componentID="4" access="read-write"> <component componentID="4" access="read-write">
<name>RxFlowControl</name> <name>RxFlowControl</name>
<synopsis> <synopsis>
A flag indicating whether receive flow control is A flag indicating whether receive flow control is
applied, defined as alias of RxFlowControl component applied, defined as alias of RxFlowControl component
in EtherMACIn LFB. in EtherMACIn LFB.
</synopsis> </synopsis>
<optional/>
<alias>boolean</alias> <alias>boolean</alias>
</component> </component>
<component componentID="5" access="read-reset"> <component componentID="5" access="read-reset">
<name>MACOutStats</name> <name>MACOutStats</name>
<synopsis> <synopsis>
The statistics of the EtherMACOut LFB The statistics of the EtherMACOut LFB
</synopsis> </synopsis>
<optional/>
<typeRef>MACOutStatsType</typeRef> <typeRef>MACOutStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="8"> <LFBClassDef LFBClassID="8">
<name>IPv4Validator</name> <name>IPv4Validator</name>
<synopsis> <synopsis>
The IPv4Validator LFB performs IPv4 validation according to The IPv4Validator LFB performs IPv4 validation according to
[RFC5812]. The IPv4 packet will be output to the [RFC5812]. The IPv4 packet will be output to the
corresponding port regarding of the validation result, corresponding port regarding of the validation result,
skipping to change at page 84, line 48 skipping to change at page 85, line 7
</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> <synopsis>
The statistics information for validating process in The statistics information for validating process in
the LFB. the LFB.
</synopsis> </synopsis>
<optional/>
<typeRef>IPv4ValidatorStatsType</typeRef> <typeRef>IPv4ValidatorStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="9"> <LFBClassDef LFBClassID="9">
<name>IPv6Validator</name> <name>IPv6Validator</name>
<synopsis> <synopsis>
The IPv6Validator LFB performs IPv6 validation according to The IPv6Validator LFB performs IPv6 validation according to
[RFC2460]. The IPv6 packet will be output to the [RFC2460]. The IPv6 packet will be output to the
corresponding port regarding of the validation result, corresponding port regarding of the validation result,
whether the packet is a unicast or a multicast one, an whether the packet is a unicast or a multicast one, an
exception has occurred or the validation failed. exception has occurred or the validation failed.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
skipping to change at page 86, line 42 skipping to change at page 86, line 50
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component access="read-write" componentID="1"> <component access="read-write" componentID="1">
<name>IPv6ValidatorStats</name> <name>IPv6ValidatorStats</name>
<synopsis> <synopsis>
The statistics information for validating process in The statistics information for validating process in
the LFB. the LFB.
</synopsis> </synopsis>
<optional/>
<typeRef>IPv6ValidatorStatsType</typeRef> <typeRef>IPv6ValidatorStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="10"> <LFBClassDef LFBClassID="10">
<name>IPv4UcastLPM</name> <name>IPv4UcastLPM</name>
<synopsis> <synopsis>
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest
Prefix Match (LPM) process. This LFB also provides Prefix Match (LPM) process. This LFB also provides
facilities to support users to implement equal-cost facilities to support users to implement equal-cost
multi-path routing (ECMP) or reverse path forwarding (RPF). multi-path routing (ECMP) or reverse path forwarding (RPF).
skipping to change at page 88, line 43 skipping to change at page 89, line 4
out a next hop selector. out a next hop selector.
</synopsis> </synopsis>
<typeRef>IPv4PrefixTableType</typeRef> <typeRef>IPv4PrefixTableType</typeRef>
</component> </component>
<component componentID="2" access="read-reset"> <component componentID="2" access="read-reset">
<name>IPv4UcastLPMStats</name> <name>IPv4UcastLPMStats</name>
<synopsis> <synopsis>
The statistics information for IPv4 unicast longest The statistics information for IPv4 unicast longest
prefix match process in the LFB. prefix match process in the LFB.
</synopsis> </synopsis>
<optional/>
<typeRef>IPv4UcastLPMStatsType</typeRef> <typeRef>IPv4UcastLPMStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="11"> <LFBClassDef LFBClassID="11">
<name>IPv6UcastLPM</name> <name>IPv6UcastLPM</name>
<synopsis> <synopsis>
The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest
Prefix Match (LPM) process. This LFB also provides Prefix Match (LPM) process. This LFB also provides
facilities to support users to implement equal-cost facilities to support users to implement equal-cost
skipping to change at page 90, line 45 skipping to change at page 91, line 6
out a next hop selector. out a next hop selector.
</synopsis> </synopsis>
<typeRef>IPv6PrefixTableType</typeRef> <typeRef>IPv6PrefixTableType</typeRef>
</component> </component>
<component componentID="2" access="read-reset"> <component componentID="2" access="read-reset">
<name>IPv6UcastLPMStats</name> <name>IPv6UcastLPMStats</name>
<synopsis> <synopsis>
The statistics information for IPv6 unicast longest The statistics information for IPv6 unicast longest
prefix match process in the LFB. prefix match process in the LFB.
</synopsis> </synopsis>
<optional/>
<typeRef>IPv6UcastLPMStatsType</typeRef> <typeRef>IPv6UcastLPMStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="12"> <LFBClassDef LFBClassID="12">
<name>IPv4NextHop</name> <name>IPv4NextHop</name>
<synopsis> <synopsis>
The LFB abstracts the process of next hop information The LFB abstracts the process of next hop information
application to IPv4 packets. It receives an IPv4 packet application to IPv4 packets. It receives an IPv4 packet
with an associated next hop identifier (HopSelector), and with an associated next hop identifier (HopSelector), and
skipping to change at page 95, line 22 skipping to change at page 95, line 33
CE without a 'RedirectIndex' metadata associated will CE without a 'RedirectIndex' metadata associated will
be dropped by the LFB. be dropped by the LFB.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameProduced> </frameProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components>
<component componentID="1">
<name>NumPacketsReceived</name>
<synopsis>
Numble of packets received from CE. A possiable
statistical information in this LFB.
</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
</components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="15"> <LFBClassDef LFBClassID="15">
<name>RedirectOut</name> <name>RedirectOut</name>
<synopsis> <synopsis>
A RedirectOut LFB abstracts the process for LFBs in the A RedirectOut LFB abstracts the process for LFBs in the
ForCES FE to deliver data packets to the ForCES CE. ForCES FE to deliver data packets to the ForCES CE.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
skipping to change at page 95, line 50 skipping to change at page 96, line 24
metadata produced (but not consumed) by previous metadata produced (but not consumed) by previous
processed LFBs should be delivered to the CE. processed LFBs should be delivered to the CE.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameExpected> </frameExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<components>
<component componentID="1">
<name>NumPacketsSent</name>
<synopsis>
Numble of packets sent to CE. A possiable
statistical information in this LFB.
</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
</components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="16"> <LFBClassDef LFBClassID="16">
<name>BasicMetadataDispatch</name> <name>BasicMetadataDispatch</name>
<synopsis> <synopsis>
The BasicMetadataDispatch LFB is defined to abstract the The BasicMetadataDispatch LFB is defined to abstract the
process in which a packet is dispatched to some output path process in which a packet is dispatched to some output path
based on its associated metadata value. Current version of based on its associated metadata value. Current version of
the LFB only allows the metadata value be 32-bits integer. the LFB only allows the metadata value be 32-bits integer.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
skipping to change at page 99, line 8 skipping to change at page 99, line 41
</synopsis> </synopsis>
<typeRef>SchdDisciplineType</typeRef> <typeRef>SchdDisciplineType</typeRef>
<defaultValue>1</defaultValue> <defaultValue>1</defaultValue>
</component> </component>
<component access="read-only" componentID="2"> <component access="read-only" componentID="2">
<name>QueueStats</name> <name>QueueStats</name>
<synopsis> <synopsis>
The QueueStats component is defined to allow the CE The QueueStats component is defined to allow the CE
to query every queue statistics in the scheduler. to query every queue statistics in the scheduler.
</synopsis> </synopsis>
<optional/>
<typeRef>QueueStatsTableType</typeRef> <typeRef>QueueStatsTableType</typeRef>
</component> </component>
</components> </components>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>QueueLenLimit</name> <name>QueueLenLimit</name>
<synopsis> <synopsis>
Allowed maximium length of each queue. The length Allowed maximium length of each queue. The length
unit is in bytes. unit is in bytes.
</synopsis> </synopsis>
 End of changes. 54 change blocks. 
86 lines changed or deleted 147 lines changed or added

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