tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6956

 
 
 

Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library

Part 5 of 5, p. 102 to 111
Prev RFC Part

 


prevText      Top      Up      ToC       Page 102 
8.  IANA Considerations

   IANA has created a registry of ForCES LFB class names and the
   corresponding ForCES LFB class identifiers, with the location of the
   definition of the ForCES LFB class, in accordance with the rules to
   use the namespace.

   This document registers the unique class names and numeric class
   identifiers for the LFBs listed in Section 8.1.  Besides, this
   document defines the following namespaces:

   o  Metadata ID, defined in Sections 4.3 and 4.4

   o  Exception ID, defined in Section 4.4

   o  Validate Error ID, defined in Section 4.4

Top      Up      ToC       Page 103 
8.1.  LFB Class Names and LFB Class Identifiers

   LFB classes defined by this document belong to LFBs defined by
   Standards Track RFCs.  According to IANA, the registration procedure
   is Standards Action for the range 0 to 65535 and First Come First
   Served with any publicly available specification for over 65535.

   The assignment of LFB class names and LFB class identifiers is as in
   the following table.

   +----------+--------------- +------------------------+--------------+
   |LFB Class | LFB Class Name |     Description        |  Reference   |
   |Identifier|                |                        |              |
   +----------+--------------- +------------------------+--------------+
   |    3     |  EtherPHYCop   | Define an Ethernet port|   RFC 6956,  |
   |          |                | abstracted at physical | Section 5.1.1|
   |          |                | layer.                 |              |
   |          |                |                        |              |
   |    4     |  EtherMACIn    | Define an Ethernet     |   RFC 6956,  |
   |          |                | input port at MAC data | Section 5.1.2|
   |          |                | link layer.            |              |
   |          |                |                        |              |
   |    5     |EtherClassifier | Define the process to  |   RFC 6956,  |
   |          |                | decapsulate Ethernet   | Section 5.1.3|
   |          |                | packets and classify   |              |
   |          |                | the packets.           |              |
   |          |                |                        |              |
   |    6     |  EtherEncap    | Define the process to  |   RFC 6956,  |
   |          |                | encapsulate IP packets | Section 5.1.4|
   |          |                | to Ethernet packets.   |              |
   |          |                |                        |              |
   |    7     |  EtherMACOut   | Define an Ethernet     |   RFC 6956   |
   |          |                | output port at MAC     | Section 5.1.5|
   |          |                | data link layer.       |              |
   |          |                |                        |              |
   |    8     | IPv4Validator  | Perform IPv4 packets   |   RFC 6956,  |
   |          |                | validation.            | Section 5.2.1|
   |          |                |                        |              |
   |    9     | IPv6Validator  | Perform IPv6 packets   |   RFC 6956,  |
   |          |                | validation.            | Section 5.2.2|
   |          |                |                        |              |
   |    10    | IPv4UcastLPM   | Perform IPv4 Longest   |   RFC 6956,  |
   |          |                | Prefix Match Lookup.   | Section 5.3.1|
   |          |                |                        |              |
   |    11    | IPv6UcastLPM   | Perform IPv6 Longest   |   RFC 6956,  |
   |          |                | Prefix Match Lookup.   | Section 5.3.3|
   |          |                |                        |              |

Top      Up      ToC       Page 104 
   |    12    |  IPv4NextHop   | Define the process of  |   RFC 6956,  |
   |          |                | selecting IPv4 next-hop| Section 5.3.2|
   |          |                | action.                |              |
   |          |                |                        |              |
   |    13    |  IPv6NextHop   | Define the process of  |   RFC 6956,  |
   |          |                | selecting IPv6 next-hop| Section 5.3.4|
   |          |                | action.                |              |
   |          |                |                        |              |
   |    14    |  RedirectIn    | Define the process for |   RFC 6956,  |
   |          |                | CE to inject data      | Section 5.4.1|
   |          |                | packets into FE LFB    |              |
   |          |                | topology.              |              |
   |          |                |                        |              |
   |    15    |  RedirectOut   | Define the process for |   RFC 6956,  |
   |          |                | LFBs in FE to deliver  | Section 5.4.2|
   |          |                | data packets to CE.    |              |
   |          |                |                        |              |
   |    16    | BasicMetadata  | Dispatch input packets |   RFC 6956,  |
   |          |    Dispatch    | to a group output      | Section 5.5.1|
   |          |                | according to a metadata|              |
   |          |                |                        |              |
   |    17    |GenericScheduler| Define a preliminary   |   RFC 6956,  |
   |          |                | generic scheduling     | Section 5.5.2|
   |          |                | process.               |              |
   +----------+--------------- +------------------------+--------------+

                                 Table 1

Top      Up      ToC       Page 105 
8.2.  Metadata ID

   The Metadata ID namespace is 32 bits long.  Below are the guidelines
   for managing the namespace.

   Metadata IDs in the range of 0x00000001-0x7FFFFFFF are Specification
   Required [RFC5226].  A metadata ID using this range MUST be
   documented in an RFC or other permanent and readily available
   reference.

   Values assigned by this specification:

   +--------------+-------------------------+--------------------------+
   |   Value      |           Name          |        Definition        |
   +--------------+-------------------------+--------------------------+
   |  0x00000000  |         Reserved        |   RFC 6956               |
   |  0x00000001  |       PHYPortID         |   RFC 6956, Section 4.4  |
   |  0x00000002  |         SrcMAC          |   RFC 6956, Section 4.4  |
   |  0x00000003  |         DstMAC          |   RFC 6956, Section 4.4  |
   |  0x00000004  |       LogicalPortID     |   RFC 6956, Section 4.4  |
   |  0x00000005  |         EtherType       |   RFC 6956, Section 4.4  |
   |  0x00000006  |          VlanID         |   RFC 6956, Section 4.4  |
   |  0x00000007  |       VlanPriority      |   RFC 6956, Section 4.4  |
   |  0x00000008  |       NextHopIPv4Addr   |   RFC 6956, Section 4.4  |
   |  0x00000009  |       NextHopIPv6Addr   |   RFC 6956, Section 4.4  |
   |  0x0000000A  |       HopSelector       |   RFC 6956, Section 4.4  |
   |  0x0000000B  |       ExceptionID       |   RFC 6956, Section 4.4  |
   |  0x0000000C  |      ValidateErrorID    |   RFC 6956, Section 4.4  |
   |  0x0000000D  |         L3PortID        |   RFC 6956, Section 4.4  |
   |  0x0000000E  |       RedirectIndex     |   RFC 6956, Section 4.4  |
   |  0x0000000F  |    MediaEncapInfoIndex  |   RFC 6956, Section 4.4  |
   |  0x80000000- |      Reserved for       |   RFC 6956               |
   |  0xFFFFFFFF  |      Private Use        |                          |
   +--------------+-------------------------+--------------------------+

                                   Table 2

Top      Up      ToC       Page 106 
8.3.  Exception ID

   The Exception ID namespace is 32 bits long.  Below are the guidelines
   for managing the namespace.

   Exception IDs in the range of 0x00000000-0x7FFFFFFF are Specification
   Required [RFC5226].  An exception ID using this range MUST be
   documented in an RFC or other permanent and readily available
   reference.

   Values assigned by this specification:

   +--------------+---------------------------------+------------------+
   |   Value      |           Name                  |   Definition     |
   +--------------+---------------------------------+------------------+
   |  0x00000000  |  AnyUnrecognizedExceptionCase   | See Section 4.4  |
   |  0x00000001  |        ClassifyNoMatching       | See Section 4.4  |
   |  0x00000002  |   MediaEncapInfoIndexInvalid    | See Section 4.4  |
   |  0x00000003  |       EncapTableLookupFailed    | See Section 4.4  |
   |  0x00000004  |             BadTTL              | See Section 4.4  |
   |  0x00000005  |     IPv4HeaderLengthMismatch    | See Section 4.4  |
   |  0x00000006  |        RouterAlertOptions       | See Section 4.4  |
   |  0x00000007  |         IPv6HopLimitZero        | See Section 4.4  |
   |  0x00000008  |       IPv6NextHeaderHBH         | See Section 4.4  |
   |  0x00000009  |      SrcAddressException        | See Section 4.4  |
   |  0x0000000A  |      DstAddressException        | See Section 4.4  |
   |  0x0000000B  |        LPMLookupFailed          | See Section 4.4  |
   |  0x0000000C  |       HopSelectorInvalid        | See Section 4.4  |
   |  0x0000000D  |      NextHopLookupFailed        | See Section 4.4  |
   |  0x0000000E  |          FragRequired           | See Section 4.4  |
   |  0x0000000F  |       MetadataNoMatching        | See Section 4.4  |
   |  0x80000000- |         Reserved for            | RFC 6956         |
   |  0xFFFFFFFF  |         Private Use             |                  |
   +--------------+---------------------------------+------------------+

                                  Table 3

Top      Up      ToC       Page 107 
8.4.  Validate Error ID

   The Validate Error ID namespace is 32 bits long.  Below are the
   guidelines for managing the namespace.

   Validate Error IDs in the range of 0x00000000-0x7FFFFFFF are
   Specification Required [RFC5226].  A Validate Error ID using this
   range MUST be documented in an RFC or other permanent and readily
   available reference.

   Values assigned by this specification:

   +--------------+---------------------------------+------------------+
   |   Value      |           Name                  |   Definition     |
   +--------------+---------------------------------+------------------+
   |  0x00000000  | AnyUnrecognizedValidateErrorCase| See Section 4.4  |
   |  0x00000001  |        InvalidIPv4PacketSize    | See Section 4.4  |
   |  0x00000002  |           NotIPv4Packet         | See Section 4.4  |
   |  0x00000003  |    InvalidIPv4HeaderLengthSize  | See Section 4.4  |
   |  0x00000004  |    InvalidIPv4LengthFieldSize   | See Section 4.4  |
   |  0x00000005  |         InvalidIPv4Checksum     | See Section 4.4  |
   |  0x00000006  |      InvalidIPv4SrcAddr         | See Section 4.4  |
   |  0x00000007  |      InvalidIPv4DstAddr         | See Section 4.4  |
   |  0x00000008  |      InvalidIPv6PacketSize      | See Section 4.4  |
   |  0x00000009  |          NotIPv6Packet          | See Section 4.4  |
   |  0x0000000A  |      InvalidIPv6SrcAddr         | See Section 4.4  |
   |  0x0000000B  |      InvalidIPv6DstAddr         | See Section 4.4  |
   |  0x80000000- |        Reserved for             | RFC 6956         |
   |  0xFFFFFFFF  |        Private Use              |                  |
   +--------------+---------------------------------+------------------+

                                   Table 4

Top      Up      ToC       Page 108 
9.  Security Considerations

   The ForCES framework document [RFC3746] provides a description of the
   security needs for the overall ForCES architecture.  For example, the
   ForCES protocol entities must be authenticated per the ForCES
   requirements before they can access the information elements
   described in this document via ForCES.  The ForCES protocol document
   [RFC5810] includes a comprehensive set of security mechanisms that
   implementations are required to support to meet these needs.  SCTP-
   based Transport Mapping Layer (TML) for the ForCES protocol [RFC5811]
   specifies security mechanisms for transport mapping for the ForCES
   protocol.  The LFBs defined in this document are similar to other
   LFBs modeled by the FE model [RFC5812].  In particular, they have the
   same security properties.  Thus, the security mechanisms and
   considerations from the ForCES protocol document [RFC5810] apply to
   this document.

10.  References

10.1.  Normative References

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5810]      Doria, A., Hadi Salim, J., Haas, R., Khosravi, H.,
                  Wang, W., Dong, L., Gopal, R., and J. Halpern,
                  "Forwarding and Control Element Separation (ForCES)
                  Protocol Specification", RFC 5810, March 2010.

   [RFC5811]      Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport
                  Mapping Layer (TML) for the Forwarding and Control
                  Element Separation (ForCES) Protocol", RFC 5811,
                  March 2010.

   [RFC5812]      Halpern, J. and J. Hadi Salim, "Forwarding and Control
                  Element Separation (ForCES) Forwarding Element Model",
                  RFC 5812, March 2010.

10.2.  Informative References

   [IEEE.802-1Q]  IEEE, "IEEE Standard for Local and metropolitan area
                  networks -- Media Access Control (MAC) Bridges and
                  Virtual Bridged Local Area Networks", IEEE Standard
                  802.1Q, 2011.

   [RFC1122]      Braden, R., "Requirements for Internet Hosts -
                  Communication Layers", STD 3, RFC 1122, October 1989.

Top      Up      ToC       Page 109 
   [RFC1812]      Baker, F., "Requirements for IP Version 4 Routers",
                  RFC 1812, June 1995.

   [RFC2460]      Deering, S. and R. Hinden, "Internet Protocol, Version
                  6 (IPv6) Specification", RFC 2460, December 1998.

   [RFC2578]      McCloghrie, K., Ed., Perkins, D., Ed., and J.
                  Schoenwaelder, Ed., "Structure of Management
                  Information Version 2 (SMIv2)", STD 58, RFC 2578,
                  April 1999.

   [RFC3746]      Yang, L., Dantu, R., Anderson, T., and R. Gopal,
                  "Forwarding and Control Element Separation (ForCES)
                  Framework", RFC 3746, April 2004.

   [RFC5226]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26,
                  RFC 5226, May 2008.

Top      Up      ToC       Page 110 
Appendix A.  Acknowledgements

   The authors would like to acknowledge the following people, whose
   input was particularly helpful during development of this document:

      Edward Crabbe
      Adrian Farrel
      Rong Jin
      Bin Zhuge
      Ming Gao
      Jingjing Zhou
      Xiaochun Wu
      Derek Atkins
      Stephen Farrell
      Meral Shirazipour
      Jari Arkko
      Martin Stiemerling
      Stewart Bryant
      Richard Barnes

Appendix B.  Contributors

   The authors would like to thank Jamal Hadi Salim, Ligang Dong, and
   Fenggen Jia, all of whom made major contributions to the development
   of this document.  Ligang Dong and Fenggen Jia were also two of the
   authors of earlier documents from which this document evolved.

   Jamal Hadi Salim
   Mojatatu Networks
   Ottawa, Ontario
   Canada
   EMail: hadi@mojatatu.com

   Ligang Dong
   Zhejiang Gongshang University
   18 Xuezheng Str., Xiasha University Town
   Hangzhou 310018
   P.R. China
   EMail: donglg@zjsu.edu.cn

   Fenggen Jia
   National Digital Switching Center (NDSC)
   Jianxue Road
   Zhengzhou 452000
   P.R. China
   EMail: jfg@mail.ndsc.com.cn

Top      Up      ToC       Page 111 
Authors' Addresses

   Weiming Wang
   Zhejiang Gongshang University
   18 Xuezheng Str., Xiasha University Town
   Hangzhou  310018
   P.R. China

   Phone: +86 571 28877751
   EMail: wmwang@zjsu.edu.cn


   Evangelos Haleplidis
   University of Patras
   Department of Electrical & Computer Engineering
   Patras  26500
   Greece

   EMail: ehalep@ece.upatras.gr


   Kentaro Ogawa
   NTT Corporation
   Tokyo
   Japan

   EMail: ogawa.kentaro@lab.ntt.co.jp


   Chuanhuang Li
   Hangzhou DPtech
   6th Floor, Zhongcai Group, 68 Tonghe Road, Binjiang District
   Hangzhou  310051
   P.R. China

   EMail: chuanhuang_li@zjsu.edu.cn


   Joel Halpern
   Ericsson
   P.O. Box 6049
   Leesburg, VA  20178
   USA

   Phone: +1 703 371 3043
   EMail: joel.halpern@ericsson.com