Internet Draft Ram Gopal Expiration: August 2002 Nokia File: draft-gopal-forces-fact-00.txt February 2002 Working Group: ForCES ForwArding and Control ElemenT protocol (FACT) draft-gopal-forces-fact-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. Abstract This document defines a FACT protocol that is suitable for communicating between Forwarding Element and Control Elements inside a network element. This protocol addresses all the requirements described in Forces [3] requirements document. This document also describes the architecture that FACT may leverage during the protocol operation. Gopal Expires August 2002 [Page 1] Internet Draft FACT protocol February 2002 Table of Content 1. Definitions.....................................................2 2. Introduction....................................................4 3. Protocol Overview...............................................5 4. Message Overview................................................6 4.1. Protocol Message structure....................................6 4.1.1. FE sending join request to CE...............................8 4.1.2. CE responding to a join request to the FE..................10 4.1.3. CE requesting FEÆs connectivity status (Health check)......11 4.1.4. FE response to heart beat request..........................12 4.1.5. Redirect Control packets to CE for processing..............13 4.1.6. CE requesting a FE for physical configuration..............14 4.1.7. FE exporting the physical configuration to CE..............15 4.1.8. Configuration change in Logical components.................16 4.1.9. FE notifying the change in port status to CE...............17 4.1.10. Topology request from CE to FE............................18 4.1.11. Topology response from FE to CE...........................18 4.1.12. Notification of CE status.................................19 4.1.13. CE forwarding a packet through FE to an output port.......21 4.1.14. CE querying the Logical components of the FE..............22 4.1.15. CE sending a command to configure logical components......23 4.1.16. Status message............................................25 5. Architecture support for FACT protocol.........................26 5.1. Security.....................................................26 5.2. High availability support....................................26 5.3. Access Control to FE.........................................26 5.4. Protocol.....................................................27 5.5. Configurable parameters......................................27 6. References.....................................................27 7. Acknowledgments................................................28 8. Authors' Addresses.............................................28 1. Definitions The following definitions are taken from [3] Forwarding Element (FE) - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per- packet processing and handling as directed by a CE via the ForCES protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs. Control Element (CE) - A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs how to process packets. CEs handle functionality such as the execution of control Gopal Expires August 2002 [Page 2] Internet Draft FACT protocol February 2002 and signaling protocols. CEs may consist of PCE partitions or whole PCEs. Pre-association Phase - The period of time during which a FE Manager (see below) and a CE Manager (see below) are determining which FE and CE should be part of the same network element. Post-association Phase - The period of time during which a FE does know which CE is to control it and vice versa, including the time during which the CE and FE are establishing communication with one another. ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES protocol" refers only to the ForCES post-association phase protocol (see below). ForCES Post-Association Phase Protocol - The protocol used for post- association phase communication between CEs and FEs. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. The ForCES protocol is a master-slave protocol in which FEs are slaves and CEs are masters. This protocol includes both the management of the communication channel (e.g., connection establishment, heartbeats) and the control messages themselves. The term ForCES protocol may refer to a suite of protocols that are used to exchange control information as well as redirect data packets between the CEs and FEs. FE Model û Modeling of logical functions in a Forwarding element line card. FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) a FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. A FE manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which CE(s) to use. Being a logical entity, a FE manager might be physically combined with any of the other logical entities mentioned in this section. CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. A CE manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which FE to use. Gopal Expires August 2002 [Page 3] Internet Draft FACT protocol February 2002 Being a logical entity, a CE manager might be physically combined with any of the other logical entities mentioned in this section. Pre-association Phase Protocol - A protocol between FE managers and CE managers that is used to determine which CEs or FEs to use. A pre-association phase protocol may include a CE and/or FE capability discovery mechanism. Note that this capability discovery process is wholly separate from (and does not replace) that used within the ForCES protocol (see Section 7, requirement #1). However, the two capability discovery mechanisms may utilize the same FE model (see Section 6). Pre-association phase protocols are not discussed further in this document (see Section 11.3). ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. To entities outside a NE, the NE represents a single point of management. Similarly, a NE usually hides its internal organization from external entities. ForCES Protocol Element - A FE or CE. Logical Component û Components in the forwarding data path like filter, meter, forwarder, shaper etc. FE Model û Organization of logical components in the Forwarding plane. 2. Introduction Network elements such as routers play an important role in transporting IP packets in the Internet. QoS aware router, policy based routing and middle-box functions such as firewall, NAT, proxies put heavy requirements on per-hop behavior treatment for IP packets. This complicates network element. Routers have emerged from simple monolithic software to a distributed routing complex that interconnects different networks and distributes the routing and forwarding logic to line cards and control cards. A line card does basic forwarding function and a control card runs all the control and management functions. Forces [3] defines both architectural and protocol requirements for the communication between CE and FE. Forwarding and Control ElemenT (FACT) protocol addresses all the requirements of Forces protocol and it is described in this document. Gopal Expires August 2002 [Page 4] Internet Draft FACT protocol February 2002 3. Protocol Overview Existing control and management protocols are designed to solve either a specific problem or a set of problems. FACT protocol is designed to communicate between FE to CE and/or between CE to CE. Since CE-CE communication is outside the scope of Forces activity, we will not discuss the CE-CE communication. FACT protocol satisfies all the Forces protocol requirements. The FACT protocol is logically separated like base control protocol and logical components service functions. This is similar to SNMP where SNMP protocol provides a set of messages and exchanges messages between SNMP manager and agent(s). MIB is the actual payload communicated in the form of BER object values between them. Similarly FACT protocol has fixed header and the payload field. The payload field carries data that may carry one of the following O Control packets which are received by FE through external port or packets that are to send to the external egress port O Logical components that are described in detail in the FE Modeling document [4] (a) Base control functions FACT protocol depends upon pre-association configuration information. This information is sent to either FE or CE by FE-Manager and CE-Manager [sec 5.5] components respectively. After the pre-association phase, FACT protocol provides mechanism and carries traffic between FE and CE components. These includes support for dynamic association, high availability, security, topology discovery of FE and CE, Control packet redirection etc. (b) Service specific functions Using the base forces protocol, any logical components inside the FE can be configured or managed. The FE modeling is flexible enough to allow any arbitrary queries. These queries are in the form of BER (Binary Encoding Rules). FE Modeling [4] is based on MIB definitions and representation in BER would be the better choice. Through out this document we describe the parameters of each logical component in the BER format. FACT protocol is independent of the type of encoding. Gopal Expires August 2002 [Page 5] Internet Draft FACT protocol February 2002 FACT protocol supports different types of messages and includes both synchronous messages like simple request/reply, asynchronous messages to notify the status and transaction oriented synchronous messages that to support 2 phase command bundling functions operations. The FACT protocol provides a notion of distributed IPC mechanism by providing support functions required for replication, high availability and fail-over support. All these features are optional and can be configured through FE-Manager for FEs during the pre- association phase. 4. Message Overview This section describes the details of each message and its format. 4.1. Protocol Message structure FACT protocol Header contains the following fields. Some of the fields are optional and it is interpreted based on the Type. All these messages are based on TLV format and conform to network byte ordering. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1 | Reserved (or) Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE-Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Identifier = 0 | B I T | Service Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: This is a 16 bit field identifies the message type. 0x01: Join message request 0x02: Join message reply 0x03: Heart beat request 0x04: Heart beat response 0x05: Redirection of packets from FE to CE 0x06: Port configuration request 0x07: Port configuration response Gopal Expires August 2002 [Page 6] Internet Draft FACT protocol February 2002 0x08: Notification of Logical component configuration change 0x09: Notification of port status change 0x0A: Topology request from CE to FE 0x0B: Topology response from FE to CE 0x0C: Notification of CE status change to FE 0x0D: Forwarding a control packet through FE 0x0E: CE sending queries to FE logical components 0x0F: CE sending command to configure logical components 0x10: Status message Length (or) Reserved: Depending on the message type, either this field contains a length of the packet in bytes or it is reserved. If this field is reserved it MUST be set to Zero Transaction Sequence Number (TSN): This 32 bit field uniquely identifies the transaction between the FE and CE. When a request is made by one endpoint (Say CE) it generates TSN number and it is sent in the request message, the other endpoint (Say FE) can copy this same TSN number in its reply message. CE Tag: During a pre-association phase CE can be configured using CE-Manager component. In a network element, there may be many CEÆs, one or more CEÆs can be grouped together to form a CE-set. A CE-set is unique in one network element and is identified by a 16-bit number. To identify a CE inside a CE- set, the CE identifier is used which is also a 16-bit field. Figure 1 shows the CE-Tag fields, CE-Tag is a 32-bit integer which has two portions, the higher order 16-bit describes the CE-set number, and the lower 16-bit describes the CE- identification number. The main advantage of having such naming is to uniquely identify the Communication elements and their logical associations inside a network element. This field is optional for certain message types. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE-Set Number | CE - Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 CE-Tag fields FE Identifier: This is a 32-bit field to uniquely identify the FE in one network element. The main advantage is that FE or CE may use different interconnect technologies, they can be identified by using the address itself (for example IP address or MAC address etc). This unique naming scheme helps to manage Gopal Expires August 2002 [Page 7] Internet Draft FACT protocol February 2002 the CE and FEÆs together and support features that are required for back-up recovery, configuration update process, and high availability support. This identifier is always present in all type of messages. BIT Fields: These 4 bits are bit fields used to represent specific capabilities or parameter types. These bit fields are interpreted according to the message types. Note: these bit fields may be removed in the next version of the document and will be represented in the FE Model as BER encoded objects. Service Data: Service Data is the payload for FACT protocol. This service data represents one of the following (1) Logical component configuration (2) Logical component statistics (3) Logical component status (4) FE capabilities and topology information (5) Command data which FE wants to send through a particular logical component output interface 4.1.1. FE sending join request to CE After the pre-association phase [5.5], the FEÆs can join and leave any CE in a CE-set. During the join request FE reports their capabilities to CE. Examples of such capabilities include whether it can support features like command bundling, 2 phase command operation, or support for high availability etc.[section 5] At a given point, CEÆs from one CE set can communicate to a FE. FEÆs has to know to which CEÆs request it can accept. This information is configured during the pre-association phase. FE uses this CE-list to send the join request. It first tries one of the CEÆs in the list and if it not successful then it tries the next CE in the list. Gopal Expires August 2002 [Page 8] Internet Draft FACT protocol February 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Identifier |P|H A S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Join request Type: set to 0x1, This 16 bit field denotes the Join request message Reserved: 16-bit field MUST be set to zero. TSN: TSN (Transaction Sequence Number), this 32 bit field uniquely identifies the transaction between the FE and CE. FE Identifier: If a FE is going to perform cold restart, this field is set to zero. Or else it will use pervious session FE identifier that was assigned to it by a CE. This field is a 16bit integer, FE identifier all zeroÆs and all 1Æs have special purpose. Bit P: When this bit is set to zero, it means that it does not provide Persistence to command sets which is required to perform 2 phase command operations. When this bit is set to ONE, it means that this FE can participate in 2-phase command operation. HAS bits: These 3 bits are optionally used to indicate whether the FE can participate in high availability mechanisms. [section 5] HAS - High availability Support -------------------------------- Gopal Expires August 2002 [Page 9] Internet Draft FACT protocol February 2002 000 No support 001 Fail over support (Weak Consistency) 011 Replicate the control packets to designated CEÆs in a CE set (Strong consistency). NOTE: This may also depend upon the type of interconnects technology being used. For example, if FE and CEÆs are connected through a shared bus or segment, this feature all the CEÆs may receive the copies of the packet. 4.1.2. CE responding to a join request to the FE After receiving a join request message, a CE performs following operations. (1) Checks the FE identifier in the request message and if it equals to zero, then the CE generates a unique for that FE. I (2) If the FE identifier field is not zero, then the CE checks up its previously stored configuration for that FE. If it has any, it will upload that configuration to FE in the reply message. This is a warm restart operation. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | Previous Configuration Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Set to 0x2, this 16 bit field denotes the Join response message Length: 16 bit field denoting the length of the packet in bytes. TSN: This 32-bit field is copied from the request packet header. Gopal Expires August 2002 [Page 10] Internet Draft FACT protocol February 2002 CE Tag: This is a 32-bit field which identifies a CE in a CE-set. FE Identifier: This is a 32-bit field that uniquely identifies a FE. CE will generate a new identifier if the FE is performing a cold start; otherwise, the FE identifier that was there in the request message is copied. Previous configuration data: This is an optional field and the size of this field is determined by length field in the FACT protocol header. If FE is performing warm restart, CE may send the FE previous configuration information in this field. 4.1.3. CE requesting FEÆs connectivity status (Health check) A CE periodically polls each FEÆs to ensure that they are operational. This message is generated by a CE. There may be more than one CE in a CE-set, to avoid duplicate request, one of the CEÆs in the CE set can generate this request. Then it up to the CEÆs to update the status of the FE. Note: Which CE will generate or perform health check is part of pre- association phase. This configuration happens through the CE- Manager. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x3 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x3, identifies Heartbeat request message Gopal Expires August 2002 [Page 11] Internet Draft FACT protocol February 2002 Reserved: 16-bit field MUST be set to zero. TSN: This 32 bit field uniquely identifies the transaction between the FE and CE. CE Tag: This is a 32-bit field that identifies a CE in a CE-set. FE Identifier: This is a 32-bit field that uniquely identifies a FE or CE can set this field to all 1Æs. NOTE: On shared interconnect medium where FE and CE are on the same LAN or BUS or segment etc. 16 bit of FE identifier is filled with all 1Æs meaning that all the FEÆs which belong to a particular CE- set should respond to the heartbeat request. This saves time and the number of heartbeat requests. This is implementation dependent and depends on interconnect. 4.1.4. FE response to heart beat request After verifying the CE-Tag, FE simply echoes the message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x4 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x4, identifies Heartbeat response message Reserved: 16-bit field MUST be set to zero. TSN: This 32 bit fields is copied from the request message. CE Tag: This is a 32-bit field that identifies a CE in a CE-set. FE Identifier: This is a 32-bit fields that uniquely identifies a FE. Gopal Expires August 2002 [Page 12] Internet Draft FACT protocol February 2002 4.1.5. Redirect Control packets to CE for processing When a router receives, both control and data packets through a physical port, the following actions may occur: (a) Forwarding blade receives an IP packet that is not destined for it. This packet is forwarded by the forwarding plane component. (b) Forwarding blade receives an IP packet that is destined for it. This packets is not forwarded to the Control plane rather it is processed by the forwarding plane control logic (stack in the forwarding plane). Examples of such packet include ping request. (c) Forwarding blade received IP packets that may be routing protocol packets or which cannot be processed by the stack in the line card, these packets have to be forwarded to the control plane by the FE. FE encapsulates the control packet along with logical component information (refer FE Modeling[4]) in the FACT header and forwards it to CE. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | Control packets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x5, identifies Re-direction message from FE to CE. Length: 16 bit field denoting the length of the packet in bytes including the FACT header. TSN: This 32 bit fields uniquely identifies the transaction. CE Tag: This is a 32-bit field that identifies a CE in a CE-set. Gopal Expires August 2002 [Page 13] Internet Draft FACT protocol February 2002 FE Identifier: This is a 32-bit fields that uniquely identifies a FE. Control Packet: The control packet that the network element received through a particular IP interface. 4.1.6. CE requesting a FE for physical configuration (Port status request) FE maintains the status of physical port and their configuration information. These models use the logical components [4]. CE at any given point can request either one or more of the egress or ingress port status. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x6 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | Sequence of Port number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x6, identifies port-status request from CE to FE. Length: 16 bit field denoting the length of the packet in bytes including the FACT header. TSN: This 32 bit fields uniquely identifies the transaction message. CE Tag: This is a 32-bit field that identifies a CE in a CE-set. FE Identifier: This is a 32-bit field that uniquely identifies a FE. Port Status Request: Logical components can be referenced inside a FE and can be referenced using BER. Gopal Expires August 2002 [Page 14] Internet Draft FACT protocol February 2002 NOTE: This field contains the sequence of BER values that are of interest to the CE. This field is optional; if this field is not present, then FE will return all the egress and ingress port status. 4.1.7. FE exporting the physical configuration to CE. (Port Status response) FE reports the requested port status by picking up the port status value from the respective logical component ( say ingress or egress port). There is another message that is asynchronous notification of change in port status [sec 4.1.8]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x7 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | Sequence of Port No and Status +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x7, identifies port-status response message from FE to CE. Length: 16 bit field denoting the length of the packet in bytes including the FACT header. TSN: This 32 bit fields which is copied from request message. CE Tag: This is a 32-bit field that identifies a CE in a CE-set which has requested the port status. FE Identifier: This is a 32-bit field that uniquely identifies a FE. Sequence of Port number and Status: This may be a sequence of BER objects and values , the BER encoded objects uniquely refers to the Gopal Expires August 2002 [Page 15] Internet Draft FACT protocol February 2002 Logical components representing the egress or ingress ports. 4.1.8. Configuration change in Logical components (Asynchronous event) FE can be configured to report the activities through either CLI or SNMP or any other mechanisms. This is optional and may be implementation dependent. Either FE can provide the list of BER encoded objects that are changed or it can simply redirect the copy of the information that it received from SNMP agent or CLI. How FE receives this information is beyond the scope of this protocol. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x8 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | Configuration Changes +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x8, identifies configuration change asynchronous event from FE to CE. Length: 16 bit field denoting the length of the packet in bytes including the FACT header. TSN: This 32 bit fields uniquely identifies the transaction message. CE Tag: This is a 32-bit field that identifies a CE in a CE-set. FE Identifier: This is a 32-bit field that uniquely identifies a FE. Gopal Expires August 2002 [Page 16] Internet Draft FACT protocol February 2002 Configuration change: This may be an BER encoded object and value pairs whose configuration is changed or it can just a string of commands what FE received from CLI sub-system. 4.1.9. FE notifying the change in port status to CE ((Asynchronous event) FE may report the change in port status to CE. The only difference between configuration change and this port message is that this message is generated by FE upon detecting a failure of port functions. It is the responsibility of the FE to keep track of the port status and it is implementation dependent. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x9 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | Sequence of Port No and Status +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x9, identifies port-status asynchronous notification message from FE to CE. Length: 16 bit field denoting the length of the packet in bytes including the FACT header. TSN: This 32 bit fields uniquely identifies the transaction message. CE Tag: This is a 32-bit field that identifies a CE in a CE-set. FE Identifier: This is a 32-bit field that uniquely identifies a FE. Gopal Expires August 2002 [Page 17] Internet Draft FACT protocol February 2002 Sequence of Port number and Status: This may be a sequence of one or more port status. Sequence of pairs of BER encoded objects and value is being sent to CE. 4.1.10.Topology request from CE to FE CE wants to know how each FE is connected or configured during the pre-association phase. This may be useful for the CE to coordinate their activities for high availability, health check etc. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0A | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x0A, identifies the topology request from CE to FE Reserved: 16-bit field MUST be set to zero. TSN: This 32 bit field uniquely identifies the transaction between the FE and CE. CE Tag: This is a 32-bit field that identifies the requesting CE in the network element. FE Identifier: This is a 32-bit fields uniquely identifies a FE. 4.1.11. Topology response from FE to CE FE manages the logical components and it requires some minimal information to communicate to CE. During pre-association phase the FE-Manager configures the FE capabilities. This includes: (1) List of CEÆs with whom it can communicate and their IP addresses or MAC addresses etc. Gopal Expires August 2002 [Page 18] Internet Draft FACT protocol February 2002 (2) May also designate one CE as primary and other as backup for asynchronous notification of events. (3) May also configures other parameters which are needed for high availability operations All these are FE capabilities that are represented in the FE Model as BER encoded objects in the FE table. FE looks into the CE-Table [FEM ], which is part of FE object, and reports to the CE. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0B | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | Topology Information +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x0B, identifies the topology response message from FE to CE Length: 16 bit field denoting the length of the packet in bytes including the FACT header. TSN: This 32 bit fields which is copied from request message. CE Tag: This is a 32-bit field that identifies a CE in a CE-set which made the topology request. FE Identifier: This is a 32-bit field that uniquely identifies a FE. Topology Information: This is a sequence of CE list that are configured during pre-association phase. FE keeps this information in the CE-Table [4] model. The response will be sequence of BER encoded objects and values. 4.1.12. Notification of CE status (or association change to FEÆs) Gopal Expires August 2002 [Page 19] Internet Draft FACT protocol February 2002 CE in a CE-set may be added or deleted from the CE-set or shutdown for maintenance reasons. Other CEÆs in the CE set may either get notification from CE-Manager ( if there is a change in configuration ) or by CE-CE communication protocol. This is beyond the scope of this protocol. In all the above cases, the CEÆs in the CE-set (one of the CE) may need to inform such configuration change to all the affected FEÆs. This message describes the changes in pre-association configuration information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0C | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | CE configuration Change +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x0C, identifies notification of configuration change from CE to FE. Length: 16 bit field denoting the length of the packet in bytes including the FACT header. TSN: This 32 bit fields uniquely identifies the transaction message. CE Tag: This is a 32-bit field that identifies a CE in a CE-set. FE Identifier: This is a 32-bit field that uniquely identifies a FE, or if this has to be notified to all the FEÆs which are managed by that CE-set then this field will be set to all 1Æs. In this case, all the FE will update their table. CE Configuration Change: This field describes the CE information which are either added or modified etc. These may be a sequence of BER attributes that FE can Gopal Expires August 2002 [Page 20] Internet Draft FACT protocol February 2002 understand and modify in its FE capability object. (i.e., CE-Table). 4.1.13. CE forwarding a packet through FE to an output port. CE may request a packet and want FE to forward that packet through a particular egress port. Examples of such packets are routing protocol updates etc. Before generating such requests, CE has to know the FEÆs logical components and the list of available ports and the configuration status. (refer snapshot of Logical components ) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0D | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | Packets to be forwarded +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x0D, identifies notification of configuration change from CE to FE. Length: 16 bit field denoting the length of the packet in bytes including the FACT header. TSN: This 32 bit fields uniquely identifies the transaction message. CE Tag: This is a 32-bit field that identifies a CE in a CE-set. FE Identifier: This is a 32-bit field that uniquely identifies a FE. Packet to be forwarded: This has two fields name the object representing egress port through which the packet has to be forwarded and then the actual packet. FE after receiving this packet it has to parse the BER encoded value fields, identifies the egress port, and forwards the packet through the port. Gopal Expires August 2002 [Page 21] Internet Draft FACT protocol February 2002 4.1.14. CE querying the Logical components of the FE FE may have one or more logical components on the forwarding plane like meter, shaper, egress port etc. CE may configure or query these components and their status at any time. In order to do this, CE needs to know the placement and sequence of the logical components in the forwarding data path. The FE Model [4] describes the arrangement and the relationships of those components. For understanding purpose, we provide the summary as follows: FE is identified by a FE identifier; FE may contain one or more parallel data paths. On each parallel data path, they may be one or more logical components and each one is connected to another either in series or in parallel fashion. The logical component is uniquely identified by a number (which needs to be IANA assigned). Examples of logical components are filter, shaper, egress port etc. Logical component attributes can be assessed by their BER encoded values. Vendor specific components can also be added. For example, the following are the few queries that may be of interest to CE. (1) To get list of All logical components (2) To get list of Attributes of one logical components (3) To configure or modify one logical components Some of these queries are useful to take a snapshot of logical components configuration, if FE needs to restart, they are uploaded as part of join request message. The FE model is flexible to handle any type of queries (similar to SNMP are possible ). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0E | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | List of BER encoded object +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gopal Expires August 2002 [Page 22] Internet Draft FACT protocol February 2002 Type: set to 0x0E identifies logical components queries CE to FE. Length: 16 bit field denoting the length of the packet in bytes including the FACT protocol header. TSN: This 32 bit fields uniquely identifies the transaction message. CE Tag: This is a 32-bit field that identifies which CE has generated the request. FE Identifier: This is a 32-bit field that uniquely identifies a FE. List of BER encoded Objects : If the length of the packet is equal to the FACT header, logical component objects and values are sent in the response message. Alternatively, FE can specifically specify a logical component specific attribute. NOTE: Response to this message is sent with message type value = 0x07. This message type is used to convey not only the port values it can convey any logical component attribute value pairs. 4.1.15. CE sending a command to configure logical components The CE might have received a command (either through CLI or through SNMP etc) to setup some tunnels, paths or some configuration. This may sometimes involve sending configuring more than one FE. That is packet may come through one line card and may leave through another line card. In this situation, CE has to configure both the FE logical components. If one of the logical components fails, it has to perform rollback operation and issues a command failure notification to the management station or CLI or SNMP etc. This operation is called command bundling. To perform this operation, A CE sends series of commands to each FE with command bundling bit set. Each FE after receiving the command will have to save the current configuration and should check whether it can program the requested configuration. The status message is sent back to the CE. Once FE receives all the status messages, it can Gopal Expires August 2002 [Page 23] Internet Draft FACT protocol February 2002 then send a execute command with same transaction sequence number, FE can now switch to new configuration. This operation will get too complicated when more than one CE trying to generate different configuration on the logical components FE if tries to do parallel activities may get into deadlock situations. It is up to the FE to react with appropriate status message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0F | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier |C S Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Logical component configuration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x0F identifies that some CE wants to configure some of the FEÆs logical component. Length: 16 bit field denoting the length of the packet in bytes including the FACT protocol header. TSN: This 32 bit fields uniquely identifies the transaction message. CE Tag: This is a 32-bit field that identifies which CE has generated the request. FE Identifier: This is a 32-bit field that uniquely identifies a FE. CS- Bit: This 3-bit field denotes the following meaning: 000 - Command is single operation no need to generate a status message to FE 001 û This command is a two-phase operation, FE needs to save the previous state if rollback operation may be performed later by FE. 010 û Rollback to the previous state. 011 û Execute and complete the command. Gopal Expires August 2002 [Page 24] Internet Draft FACT protocol February 2002 During this operation the TSN value is same and used to identify the transaction. The same CE should generate this TSN otherwise, FE will treat this as different query from other CE. Logical Component Configuration: List of BER encoded object values that are to be configured. 4.1.16. Status message CE or FE may generate a status message to inform one of the following events. This list is not exhaustive (to be added later) Status Code Description ----------------------------------------------------------------- 0x100 FE sending a command failure notification to CE 0x101 FE information failure to communicate to CE 0x102 FE receiving request from another CE set 0x103 FE sending a shutdown message to CE 0x104 CE sending a shutdown message to FE 0x105 FE is in two-phase command lock 0x106 FE could not complete the 2-phase command 0x400 success 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x10 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE - Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE - Identifier | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: set to 0x10 identifies status message Reserved: Must be set to zero. TSN: (1) CE or FE might have request certain operation. The status message may be generated which will provide the completion status. (2) For certain type of status like shutdown of FE or CE, the TSN field is just a unique identifier. Based on the status code this field is identified. Gopal Expires August 2002 [Page 25] Internet Draft FACT protocol February 2002 CE Tag: This is a 32-bit field that identifies which CE FE Identifier: This is a 32-bit field that uniquely identifies a FE. 5. Architecture support for FACT protocol Pre-association phase is used to configure certain key attributes. FE-Manager and CE-Manager are responsible for providing that information. 5.1.Security If FE or CE is going to communicate over a non-secure domain, then it is the responsibility of the administrator to choose appropriate lower layer security protocols. For example if the FE and CE are communicating in a shared LAN or Ethernet etc, then layer 2 encryption is used. If it is going be above IP layer either TLS or IPSec can be used. FACT protocol is just a payload for those protocols and does not carry any explicitly fields for authentication or encryption. 5.2. High availability support Fail-over, load sharing etc, are part of high-availability treatment. Since CE-CE communication is out of scope (but FACT protocol can be applied there also). FE-Manager can configure FE to perform one of the following functions . Strong consistency : Send all asynchronous notification to the entire CE in the CE set. . Weak consistency: Send all the asynchronous notification events only to one CE in the CE set, that CE may be acting as primary CE, when that CE is not active use the next one in the list or a backup CE. This type of requirement does not affect the protocol. The protocol has provision and bit fields to communicate the FE capabilities to CE during the join message request. 5.3. Access Control to FE It is up to the implementer to configure the number of CE that can access FE, as such protocol is flexible and has 16-bit fields to identify a CE. Gopal Expires August 2002 [Page 26] Internet Draft FACT protocol February 2002 5.4. Protocol (1) FACT protocol does not handle reliability and congestion control mechanism and it is expected to run on top of a transport protocol which provides reliable, sequence delivery and also incorporates congestion control mechanisms. These functions are already provided by transport protocols like TCP or SCTP or RDP. (2) FACT can also be applied to shared LAN or in a single HOP and if the link layer provides the flow control and reliable delivery this FACT protocol can be used. 5.5. Configurable parameters The following are the currently identified configurable parameters that can be configured through FE-Manager and CE-Manager for FE and CEÆs respectively (1) Load Sharing (optional) (2) Fail over configuration (optional) (3) Load Balancing (optional) (4) Security Keys (optional) (5) Number of CE to which it has to communicate (6) Maximum number of CE (7) Whether FE should notify to CEÆs regarding the change in configuration ( which happened via SNMP or CLI ) (8) Timer for health check 6. References 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, October 1996. 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC2119 (BCP), IETF, March 1997. 3. Anderson, et. al., "Requirements for Separation of IP Control and Forwarding", work in progress, February 2002,,IETF. 4. Ram Gopal, "Forwarding Element Modelling",work in progress, February 2002, , IETF Gopal Expires August 2002 [Page 27] Internet Draft FACT protocol February 2002 7. Acknowledgments I would like to thank Man Li, Nokia Research Center for her suggestions and comments. 8. Authors' Addresses Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803 Phone: 1-781-993-3685 Email: ram.gopal@nokia.com Gopal Expires August 2002 [Page 28]