Internet Draft W. Wang Expiration: Feb 2004 Hangzhou Univ.of Commerce File: draft-wang-forces-model-topology-00.txt Working Group: ForCES August 2003 Topology Representation for ForCES FE Model draft-wang-forces-model-topology-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. Abstract This document introduces an approach to represent FE block topology and FE topology for ForCES FE model. This document also defines the corresponding messages for ForCES protocol to report, configure and modify topology for ForCES FE model. Table of Contents Abstract..........................................................1 1. Introduction...................................................2 2. Definitions....................................................2 3. ForCES FE block topology and FE topology.......................3 4. FE block topology representation...............................5 4.1. PkfIDs to mark FE block topology..........................5 4.2. PkfID data format.........................................8 4.3. Topology representation using PkfIDs......................8 4.3.1. Block-Centered Approach..............................9 4.3.2. Connection-Centered Approach........................13 4.3.3. Comments on the two representation approaches.......16 Internet Draft Topology Representation for ForCES Aug. 2003 4.4. Topology modification using PkfIDs.......................16 4.5. Topology report..........................................17 5. Block attribute representation using PkfIDs...................20 6. FE topology representation using PkfIDs.......................22 7. Security Considerations.......................................25 8. References....................................................25 8.1. Normative References.....................................25 8.2. Informative References...................................26 9. Acknowledgments...............................................26 10. Authors' Addresses...........................................26 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 [RFC-2119]. 1. Introduction The Concept of IP Forwarding and Control Element Separation (ForCES) separates a general Network Element (NE) into a control plane and a forwarding plane[FORCES-REQ]. The control plane is composed of one or more Control Elements (CEs). The forwarding plane is composed of one or more Forwarding Elements (FEs) connected into the FE topology. Each FE is modeled by multiple functional building blocks that connect into a complex FE block topology. The CE can query the FE topology and block topology; it can also configure and control FE block topology. As a result, efficient topology representation for FE model is extremely important. This document introduces a simple and effective approach for topology representation in ForCES FE model. It defines a notion called Packet Flow Identifier (PkfID)[GRMP-WANG]. By using PkfIDs, FE block topology can be represented clearly and efficiently, and then can be manipulated by the CE. PkfIDs also makes some block attributes easily represented and manipulated. PkfIDs can also be used for FEs to report FE topology to CEs. This document is directly applicable for ForCES Working Group, but the approach introduced in this document may also be applied to other IETF Work such as GSMP and CCAMP, where a scenario of an entity composed of building blocks and the block topology being controlled by an outside controller may exist. 2. Definitions This document follows the definitions from [FORCES-REQ] and [FORCES- FRM]. We also introduce new terminology like Packet Flow Id etc. Wang Expires Feb. 2004 [Page 2] Internet Draft Topology Representation for ForCES Aug. 2003 FE model - A model that describes the logical processing functions of an FE. FE block topology - Representation of how functional building blocks in an FE are interconnected. FE topology - Representation of how multiple FEs in a NE are interconnected. It is inter-FE topology, distinguished from intra-FE topology, that is FE block topology. FE topology is within the scope of ForCES architecture, but out of the scope of FE model. Even so this document still does some work on it because it is also essential for ForCES protocol. Packet Flow Identifier (PkfID) - Identifier to describe a datapath in FE model. The datapath is shown in FE block topology as a connection between blocks or in FE topology as a connection between FEs. Packet Flow Single Identifier (PkfSID) - A subset of PkfIDs, which is used to describe a single connection for FE block topology or FE topology. Packet Flow Group Identifier (PkfGID) - A subset of PkfIDs, which is used to describe a group of connections that usually come from or go to the same FE block in FE model. 3. ForCES FE block topology and FE topology As defined in [FORCES-FRM], a ForCES FE block topology represents how FE building blocks within an FE are interconnected. An FE building block can be generically described as a block with M ingresses and N egresses, as shown in Figure 1. Note that it is possible some block has no ingress or egress, e.g., a dropper block does not have any egress. The block functional states including the numbers M,N SHOULD be configured by the CE, while the block MAY have the ability to report its capability, performance statistics, etc to CEs, via an implicit connection with CEs. Here 'implicit' means this connection is internally and automatically setup by ForCES protocol slave part inside an FE. There is no need for ForCES protocol to explicitly describe and manipulate the connection. Therefore there is no need for FE block topology to describe it. Control plane CEs | ^ v | Configure Report | ^ v | +---------+ Wang Expires Feb. 2004 [Page 3] Internet Draft Topology Representation for ForCES Aug. 2003 Ingress #1-->|1 1|--> Egress #1 ... | | ... Ingress #M-->|M N|--> Egress #N +---------+ Figure 1. A Generic FE Building Block Multiple FE blocks interconnected by datapath connections form a functional FE block topology. Figure 2 and Figure 3 shows two examples of such topology [RFC3290,MODEL-YANG]. Meter Mux +--+ +--+ | 1|------------>|1 | +->| | | |--+ | | 2|--+ +->|2 | | | +--+ | +--+ | +--+ | | +->| |-+ | | +--+ | +---+ | Marker | +---+ +---+ | 1|---+ +->|1 |------>|1 | | | | | | | | 2|------------------------------->|2 |------>|2 | | | | | | | ------>| 3|------------------------------->|3 |------>|3 |----> | | | | | | | 4|------------------------------->|4 |------>|4 | | | | | | | | 5|------------------------------->|5 |------>|5 | +---+ +---+ +---+ Classifier Queues Scheduler Figure 2. An example of an FE block topology Input +------------+ +------------+ ------->|1 1|-->| | output | | | | +------------+ ------->|2 2|-->| |-->|1 1|-----> | Ingress | | | | | ------->|3 Port 3|-->| IPv4 L3 |-->|2 Egress 2|-----> | Mgr | | LPM | | Port | ------->|4 4|-->| Forwarder |-->|3 Mgr 3|-----> | | | | | | ------->|5 5|-->| |-->|4 4|-----> | | | | +------------+ ------->|6 6|-->| | +------------+ +------------+ Figure 3. Another example of an FE block topology Wang Expires Feb. 2004 [Page 4] Internet Draft Topology Representation for ForCES Aug. 2003 Shown in Figure 2 is a typical CBQ (Classifier, Buffer, Scheduler) architecture based IP QoS router topology; while shown in Figure 4 is a general FIFO IP router topology where ingress and egress ports are individually managed by the port manager block. FE topology is the topology describing how multiple FEs are interconnected within a NE. Figure 4 shows an example of an FE topology. +---------+ +---------+ <------>| FE1 |<---------->| FE3 |<------> | |<--- --->| | +---------+ \ / +---------+ \/ +---------+ /\ +---------+ <------>| FE2 |<---/ \--->| FE4 |<------> | |<---------->| | +---------+ +---------+ Figure 4. An example of an FE topology 4. FE block topology representation According to ForCES requirements, a CE must be able to configure and reconfigure FE block topology via ForCES protocol [NL2-SALIM, FACT], and an FE must be able to report its block topology to the CE via the protocol. Hence. an efficient representation of FE block topology is very important. In this section, we will first introduce an effective approach to FE block topology representation, and then introduce how ForCES protocol can manipulate FE block topology based on this approach. The approach is based on Packet Flow Identifier (PkfID). 4.1. PkfIDs to mark FE block topology As defined in section 2, a Packet Flow Identifier (PkfID) is a name to identify a datapath that connects two or more FE blocks together. A datapath connection in FE block topology usually comes from one block egress and goes to one or more block ingresses. We can mark all connections in an FE block topology with many PkfIDs. The marked topology is then called PkfID marked FE block topology. Note that a connection from one block egress to many ingresses of other blocks (this may be used for broadcast or multicast) is only treated as one connection and marked with one PkfID. In order to compactly mark FE block topology with PkfIDs, we define two kinds of PkfIDs: Packet Flow Single Identifiers (PkfSIDs) and Packet Flow Group Identifiers (PkfGIDs). A PkfSID is used to mark a Wang Expires Feb. 2004 [Page 5] Internet Draft Topology Representation for ForCES Aug. 2003 single connection, while a PkfGID is used to mark a group of connections that usually come from the same block or go to the same block. A PkfGID marked connections act quite like a bus connections. Figure 5 shows the result of the FE block topology in Figure 2 that are marked with PkfSIDs. Meter Mux +--+ PkfSID8 +--+ | 1|------------>|1 | PkfSID11 +->| | PkfSID10 | |--+ | | 2|--+ +->|2 | | | +--+ | +--+ | +--+ | PkfSID2| +->| |-+ | | PkfSID9 +--+ | +---+ | Marker | +---+PkfSID12+---+ | 1|---+ +->|1 |------->|1 | | |PkfSID3 | |PkfSID13| | | 2|------------------------------->|2 |------->|2 |Pkf PkfSID1| | PkfSID4 | |PkfSID14| |SID17 ------>| 3|------------------------------->|3 |------->|3 |----> | | PkfSID5 | |PkfSID15| | | 4|------------------------------->|4 |------->|4 | | | PkfSID6 | |PkfSID16| | | 5|------------------------------->|5 |------->|5 | +---+ +---+ +---+ Classifier Queues Scheduler Figure 5. An FE block topology marked by PkfSIDs To precisely mark FE block topology with PkfGIDs, we need to define something more: PkfGID[M:N] - Representing a group of connections assigned with PkfGID name and the individual connections are assigned numbers from M to N contiguously. PkfGID[M] - Representing a single connection within a PkfGID connection group, the connection is in the M numbered place. Then, by using PkfGIDs, the topology in Figure 3 can be marked as in Figure 6. +---------+ +----------+ Input | | | | output | | | | +---------+ PkfGID1 | |PkfGID2| |PkfGID3| | PkfGID4 [1:6] | |[1:6] | |[1:4] | | [1:4] ------\|1 1|------\|1 1|------\|1 1|-------\ ------/|~ ~|------/|~ ~|------/|~ ~|-------/ Wang Expires Feb. 2004 [Page 6] Internet Draft Topology Representation for ForCES Aug. 2003 |6 6| |6 4| |4 4| | Ingress | | IPv4 L3 | | Egress | | Port | | LPM | | Port Mgr| | Mgr | | Forwarder| +---------+ | | | | +---------+ +----------+ Figure 6. An FE block topology marked by PkfGIDs It is obvious using PkfGIDs can simplify topology marking process. Both PkfGIDs and PkfSIDs can be mixed to use in an FE block topology to efficiently mark a complex topology. As an example, we show a PkfGID and PkfSID mixedly marked result for Figure 2 in Figure 7. Meter Mux +--+ PkfSID2 +--+ PkfGID1[1] | 1|------------>|1 | PkfSID5 +->| | PkfSID4 | |--+ | | 2|--+ +->|2 | | | +--+ | +--+ | +--+ | | +->| |-+ | | | PkfSID3 +--+ | +---+ | | Marker | +---+ +---+ | 1|-|-+ +->|1 | | | | | | | |PkfGID2 | |Pkf PkfSID1| | | PkfGID1[2:5] | |[1:5] | |SID6 ------>| 2|-|-----------------------------\|2 1|-------\|1 |----> | ~|-|-----------------------------/|~ ~|-------/|~ | | 5| | |5 5| |5 | | | |<=PkfGID1[1:5] | | | | | | | | | | +---+ +---+ +---+ Classifier Queues Scheduler Figure 7. An FE block topology marked mixedly by PkfSIDs and PkfGIDs Note in Figure 7 that, the classier outputs are all marked by a group PkfGID1, so the single connection to Meter block is marked as PkfGID1[1] which belongs to PkfGID1 group. Also note that the M,N number used by PkfGID has nothing to do with any block port number. As can be shown later, after an FE block topology is marked with PkfIDs, the block ingress or egress port numbers are not used any more. Any block actions toward ports can be implemented just by using the marked PkfIDs. Theoretically, any block with multiple outputs can be marked by PkfGIDs. The more the outputs, the more efficient the PkfGID describes. But if the number of outputs is very small, such as only 2 Wang Expires Feb. 2004 [Page 7] Internet Draft Topology Representation for ForCES Aug. 2003 or 3 ports, and the port connections go to different blocks, maybe it is more efficient to use PkfSID to mark them. 4.2. PkfID data format Because PkfIDs are assigned by CE via ForCES protocol messages, we need to define PkfID data format for ForCES protocol to use. PkfID data format can be defined as follows: A PkfSID is assigned 32bits, with first bit set to 0, as below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| PkfSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A PkfGID is assigned 16bits, with first bit set to 1 and second bit as a tag to indicate if the assigned is a PkfGID[M] or a PkfGID[M:N], as below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|G| PkfGID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, G=0 - PkfGID[M] G=1 - PkfGID[M:N]. The numbering in a connection group is expressed by 16bits data. So a PkfGID[M] is expressed as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PkfGID | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ While PkfGID[M:N] is expressed using 64bits as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| PkfGID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M | N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3. Topology representation using PkfIDs In this section we discuss how to represent the topology information in the ForCES protocol message so that the CE can manipulate the topology. Depending on two different perspectives of a PkfID marked topology, We can use two different approaches to represent the topology. Wang Expires Feb. 2004 [Page 8] Internet Draft Topology Representation for ForCES Aug. 2003 4.3.1. Block-Centered Approach From perspective of blocks, a PkfID marked FE block topology can be viewed as only composed of PkfID marked blocks. A PkfID marked block has its ingresses and egresses all marked with PkfIDs. It means a PkfID marked block has included its connection information in it. To fully represent a PkfID marked block, we need to list out all the PkfIDs connected to it as well as the block attributes. As an example, we show a PkfID marked classifier block in Figure 7 as in Figure 8. +-----+ | | PkfSID1 | |PkfGID1[1:5] ------->|1 1|-----\ | ~|-----/ | 5| | | +-----+ Classifier Figure 8. A PkfID marked block As a result, to represent a topology, we only need to represent and list out all the PkfID marked blocks in it. Any receiver of the information can then reconstruct the topology based on the PkfID expressed interconnections. In ForCES protocol, the process to represent PkfID marked blocks can be jointly implemented along with the process for ForCES CE to mount blocks to FEs. After all blocks associated with PkfIDs are mounted to FEs, the topology information for an FE model is also implicitly transferred to the FE. As a result, topology configuration does not take any more ForCES protocol messages. We now describe the detailed process for this topology representation in ForCES protocol. We use a function MountBlock() to represent ForCES block mounting message. This message mounts a block to an FE. We incorporate PkfIDs that have marked this block in it, then the message may have following message format: MountBlock( u16 FE-ID; Msg-Tag; u16 BlockType; ThisBlockInstanceID; u16 IngressNumber; EgressNumber; (List of PkfIDs on Ingresses) (List of PkfIDs on Egresses) .... Wang Expires Feb. 2004 [Page 9] Internet Draft Topology Representation for ForCES Aug. 2003 (other block attributes) .... ) Where, u16,_u32,_u64: 16bits, 32bits and 64bits(note that for precise expression, parameters in one line individually occupy the same bits assigned at the line head, which means FE-ID and Msg-Tag individually occupy 16bits); FE-ID: the FE identifier this block is in; Msg-Tag: tags needed for this message; currently we define: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg-Tag = |P|A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, P = 0 - the block mounting message does not contain PkfIDs = 1 - the message contains PkfIDs A = 0 - the block mounting message does not contain attributes = 1 - the message contains attributes By defining the P and A tag, the block mounting message can be used for block PkfIDs setup or only for attributes setup; BlockType: this block type; ThisBlockInstanceID: this block instance identifier; IngressNumber,EgressNumber: number of ingresses and egresses for this block, it is used to correctly position followed PkfIDs. List of PkfIDs on Ingresses and Egresses: list of PkfIDs in data format defined in Section 4.2. Note that PkfIDs do not need to be assigned to specific block ports such as port #1, port #3. As we will discuss in section 5 on block attributes, a PkfID represented model does not care about specific port numbers after operations in blocks are defined to operate directly towards PkfIDs. Also note that, we describe ForCES protocol messages here only on the part that relates to topology operation. We do not mean to define a precise format for ForCES protocol, which should be done by specific ForCES protocol document. Therefore we have not included things like message headers here. In ForCES message header, there MAY be information like CE-Tag, FE-Identifier, Transaction Sequence Number[FACT], where FE-Identifier means the FE the message is going to send, which MAY be different from FE-ID presented here. This means block topology configuration of one FE in FE topology MAY be implemented via an FE that is directly connected to a CE. But current Wang Expires Feb. 2004 [Page 10] Internet Draft Topology Representation for ForCES Aug. 2003 ForCES framework has defined every FE is connected to at least one CE, in this case, the two FE-Identifiers are actually the same. By using the above ForCES block mounting message, we show below the process for a CE to mount and configure the FE blocks and the block topology for Figure 7: 1) FoCES CE sends a Classifier block mounting message to FE MountBlock( u16 FE-ID; Msg-Tag(P=1,A=1); u16 BlockType(=CLASSIFIER); ThisBlockInstanceID; u16 IngressNumber(=1); EgressNumber(=5); u32 PkfSID1; u64 PkfGID1[1:5]; .... ) 2) CE sends a Meter block mounting message to FE MountBlock( u16 FE-ID; Msg-Tag(P=1,A=1); u16 BlockType(=METER); ThisBlockInstanceID; u16 IngressNumber(=1); EgressNumber(=2); u32 PkfGID1[1];PkfSID2;PkfSID3; .... ) 3) CE sends a Marker mounting message to FE MountBlock( u16 FE-ID; Msg-Tag(P=1,A=1); u16 BlockType(=MARKER); ThisBlockInstanceID; u16 IngressNumber(=1); EgressNumber(=1); u32 PkfSID3;PkfSID4; .... ) 4) CE sends a Mux mounting message to FE MountBlock( u16 FE-ID; Msg-Tag(P=1,A=1); u16 BlockType(=MUX); ThisBlockInstanceID; u16 IngressNumber(=2); EgressNumber(=1); u32 PkfSID2;PkfSID4;PkfSID5; .... ) 5) CE sends a Queues block mounting message to FE Wang Expires Feb. 2004 [Page 11] Internet Draft Topology Representation for ForCES Aug. 2003 MountBlock( u16 FE-ID; Msg-Tag(P=1,A=1); u16 BlockType(=QUEUES); ThisBlockInstanceID; u16 IngressNumber(=5); EgressNumber(=5); u32 PkfSID5; u64 PkfGID1[2:5]; u64 PkfGID2[1:5]; .... ) 6) CE sends a Scheduler mounting message to FE MountBlock( u16 FE-ID; Msg-Tag(P=1,A=1); u16 BlockType(=SCHEDULER); ThisBlockInstanceID; u16 IngressNumber(=5); EgressNumber(=1); u64 PkfGID2[1:5]; u32 PkfSID6; .... ) After all these ForCES messages are sent, the blocks and block topology of the FE model in Figure 7 is setup in the FE. Actually the order of these block mounting messages does not matter. We can also define a block topology setup message for ForCES protocol. We call it a block-centered topology setup message. By using this message, all the blocks can be mounted and set up in one message, though the block attributes need to be added afterwards. TopologySetupBlock( u16 FE-ID; Reserved; u16 BlockNumber; Reserved; u16 BlockType; ThisBlockInstanceID; /* first block*/ u16 IngressNumber; EgressNumber; (List of PkfIDs on Ingresses) (List of PkfIDs on Egresses) u16 BlockType;ThisBlockInstanceID; /* secondblock*/ u16 IngressNumber; EgressNumber; (List of PkfIDs on Ingresses) (List of PkfIDs on Egresses) ... /* other blocks*/ ) By using block-centered topology setup message, we show the setup of FE block topology for Figure 6 as below: Wang Expires Feb. 2004 [Page 12] Internet Draft Topology Representation for ForCES Aug. 2003 TopologySetupBlock( u16 FE-ID; Reserved; u16 BlockNumber(=3); Reserved; u16 BlockType(=IngressPortMgr); ThisBlockInstanceID; u16 IngressNumber(=6); EgressNumber(=6); u64 PkfGID1[1:6]; PkfGID2[1:6]; u16 BlockType(=IPv4LPMForwarder);ThisBlockInstanceID; u16 IngressNumber(=6); EgressNumber(=4); u64 PkfGID2[1:6]; PkfGID3[1:4]; u16 BlockType(=EgressPortMgr);ThisBlockInstanceID; u16 IngressNumber(=4); EgressNumber(=4); u64 PkfGID3[1:4]; PkfGID4[1:4]; ) It is obvious this setup process is precise. 4.3.2. Connection-Centered Approach From perspective of connections, a PkfID marked FE block topology can be viewed as composed of connections marked with PkfIDs. A PkfID marked connection comes from a block output and goes to one or more block inputs. A PkfID can either be a PkfSID or a PkfGID. We show A PkfSID marked connection PkfSID2 in Figure 7 as in Figure 9. Meter Mux +--+ PkfSID2 +--+ | 1|------------>|1 | | | | | | 2| |2 | +--+ +--+ Figure 9. A PkfSID marked connection If the PkfID is a PkfGID, the connection looks a little more complex. Figure 10 shows the PkfGID1 group connections in Figure 7. +--+ PkfGID1[1] | 1| +->| | | | 2| | +--+ | Meter +---+ | | +---+ Wang Expires Feb. 2004 [Page 13] Internet Draft Topology Representation for ForCES Aug. 2003 | 1|-|-+ |1 | | | | | | | | | PkfGID1[2:5] | | | 2|-|-----------------------------\|2 1| | ~|-|-----------------------------/|~ ~| | 5| | |5 5| | | |<=PkfGID1[1:5] | | | | | | +---+ +---+ Classifier Queues Figure 10. PkfGID marked group connections In order for a CE to configure an FE block topology from perspective of connections, ForCES protocol needs to define a connection-adding message. According to the added connection being a single connection or a group of connections, the message format is different. We present the two message formats as below: 1) Add a single connection To add a PkfSID marked connection, we only need to list the PkfSID name and all the blocks the connection is from and all the blocks the connection is to. AddConnection( u16 FE-ID; Reserved; u32 PkfSID; /*the connection name*/ u16 FromBlockNumber; ToBlockNumber; u16 BlockType;ThisBlockInstanceID; /*from blocks*/ ... u16 BlockType;ThisBlockInstanceID; /* to blocks*/ .... ) Where, FromBlockNumber, ToBlockNumber: numbers of blocks the connection is from and goes to. This is used to position followed block data. Usually, for a PkfSID described single connection, the FromBlockNumber is only one. 2) Add a connection group To add aPkfGID marked group of connections, more information needs to be listed, for it is possible only a branch of the PkfGID is connected to a block or PkfGID may be cut into many branches then be connected to one block. For instance, for Figure 10, it is also possible PkfGID[2] is connected to the Meter while PkfGID[1:2] and PkfGID[4:5] are connected to queues. Therefore we need to list all the PkfGID branches one by one. In order to position the PkfGID Wang Expires Feb. 2004 [Page 14] Internet Draft Topology Representation for ForCES Aug. 2003 branches correctly, the branch number also needs to be told. Therefore, a group connection adding message is defined as follows: AddConnection( u16 FE-ID; Reserved; u64 PkfGID[M:N]; /*the PkfGID name*/ u16 FromBlockNumber;ToBlockNumber; u16 BlockType;ThisBlockInstanceID; /*first from block*/ u16 PkfGBranchNumber;16bitsReserved; (list of PkfGID branches connected to this block) ... u16 BlockType;ThisBlockInstanceID; /*first to block*/ u16 PkfGBranchNumber;16bitsReserved; (list of PkfGID branches connected to this block) .... /*for other blocks connected*/ ) Where, PkfGBranchNumber: PkfGID branch number connected to this block. Note that, for group connections, it is possible there are multiple blocks the group comes from and multiple blocks the group goes to. As an example, we show the message to add group connections PkfGID1 in Figure 10 as below: AddConnection( u16 FE-ID; Reserved; u32 PkfGID1[1:5]; u16 FromBlockNumber(=1);ToBlockNumber(=2); u16 BlockType(=CLASSIFIER);ThisBlockInstanceID;/*fromblock*/ u16 PkfGBranchNumber(=1);16bitsReserved; u64 PkfGID1[1:5]; u16 BlockType(=METER);ThisBlockInstanceID; /*to blocks*/ u16 PkfGBranchNumber(=1);16bitsReserved; u32 PkfGID[1]; u16 BlockType(=QUEUES);ThisBlockInstanceID; u16 PkfGBranchNumber(=1);16bitsReserved; u64 PkfGID[2:5]; Wang Expires Feb. 2004 [Page 15] Internet Draft Topology Representation for ForCES Aug. 2003 ) The different message format for PkfSID and PkfGID can be recognized just by checking the bit in the first PkfID in the message, which distinguish PkfSID from PkfGID. In order for a CE to configure an FE block topology in connection- centered approach, ForCES protocol needs to send messages to add all defined PkfIDs to an FE. This process SHOULD be done after all FE blocks have been mounted without using PkfIDs Msg-Tag's P=0 in block mounting message). A specific connection-centered topology setup message can also be defined, so that the whole topology can be setup only by using one ForCES protocol message. 4.3.3. Comments on the two representation approaches To construct topology using connection-centered approach, we need to use additional ForCES connection adding messages as well as block mounting messages. While using block-centered approach, we only use ForCES block mounting messages then the topology can be configured implicitly. Therefore we RECOMMEND using the block-centered approach to first configure FE block topology and then the connection-centered approach to modify the topology such as to add a new connection, delete an existing connection or modify a connection. Section 4.4 describes how these operations are realized. 4.4. Topology modification using PkfIDs An FE block topology represented by PkfIDs can be modified on the fly during the FE runtime. This meets the ForCES dynamic configuration requirement. Dynamic topology configuration is often used in ForCES protocol application layers like in Diffserv, RSVP and MPLS, where a large amount of packet flows may be modified according to runtime status. Note that connections defined by PkfIDs are abstractive ones. We may have many PkfID marked connections in a topology that are in FE implementation plane only one physical connection. PkfIDs act like global variables in FE implementation layer, FE implementation codes use them as indexes to fetch a packet from a correct place or put a packet to a specified place so that other processing modules can fetch it. As a result, number of PkfIDs that can be defined are mainly limited by memory size that can be used as global variables in FE implementation layer. As we know from PkfID data format, a PkfID only takes 32bits or 64bits memory size, therefore number of PkfIDs that FE implementation layer can support is reasonably large. Wang Expires Feb. 2004 [Page 16] Internet Draft Topology Representation for ForCES Aug. 2003 We define three kinds of modification operations for PkfID marked connections that correspond to three ForCES protocol messages: 1) Add a new connection This is exactly the AddConnection() ForCES protocol message defined in Section 4.3.2. By using this message, a new PkfSID marked connection or a PkfGID marked connection group can be added to FE model. 2) Delete an existing connection To delete an existing PkfID marked connection is just to delete the PkfID. So the message has format as: DeleteConnection( u16 FE-ID; Reserved; u32/u64 PkfID; ) Where, PkfID = {PkfSID | PkfGID[M] | PkfGID[M:N]}. 3) Modify an existing connection In order to simplify the operation, we define that to modify an existing connection is to first delete the connection and then add a new connection. So we define the format for ForCES connection modifying message exactly the same as AddConnection(). When ForCES execute the message, it first deletes the connection indicated by the PkfID first, then re-adds the PkfID marked connection according to the message information. 4.5. Topology report According to ForCES requirements, a CE may ask an FE to report its current block topology to the CE. Based on PkfIDs, we define following ForCES messages to meet this topology report requirement: 1) Topology request message This message is sent from a CE to an FE to query the current block topology of a specified FE. TopologyRequest( u16 FE-ID; Reserved; } Wang Expires Feb. 2004 [Page 17] Internet Draft Topology Representation for ForCES Aug. 2003 2) Topology request response message This message is sent by an FE to report its current block topology to the requested CE. TopologyRequestResponse( u16 FE-ID; Reserved; u16 BlockNumber; Reserved; u16 BlockType; ThisBlockInstanceID; /*first block*/ u16 IngressNumber; u16 EgressNumber; (List of PkfIDs in Ingresses) (List of PkfIDs in Egresses) u16 BlockType; ThisBlockInstanceID; /*second block*/ u16 IngressNumber; u16 EgressNumber; (List of PkfIDs in Ingresses) (List of PkfIDs in Egresses) ... /*other blocks*/ ) This message format is actually based on the block-centered topology representation, and it has same format as TopologySetupBlock() message in Section 4.3.1. 3) Block connection state request message This message is sent from a CE to an FE to request the current connection state of a specific block. BlockConnectionRequest( u16 FE-ID;Reserved; u16 BlockType; ThisBlockInstanceID; } 4) Block connection state response message This message is sent from an FE to a CE to report the current connection state of a specific block. BlockConnectionResponse( u16 FE-ID; Reserved; u16 BlockType; ThisBlockInstanceID; u16 IngressNumber; EgressNumber; (List of PkfIDs on Ingresses) (List of PkfIDs on Egresses) Wang Expires Feb. 2004 [Page 18] Internet Draft Topology Representation for ForCES Aug. 2003 ) 5) A connection status request message This message is sent from a CE to an FE to request the state of a PkfID marked connection. ConnectionStateRequest( u16 FE-ID; Reserved; u32/u64 PkfID; ) Where, PkfID= {PkfSID | PkfGID[M] | PkfGID[M:N]}. 6) A connection state response message This message is sent from a EE to a CE to report the state of a PkfID marked connection. According to the requested different PkfID type, it has different format: If the requested PkfID is PkfSID or PkfGID[M], the format is: ConnectionStateResponse( u16 FE-ID; Reserved; u32 PkfID; /*the connection name*/ u16 FromBlockNumber;ToBlockNumber; u16 BlockType; ThisBlockInstanceID; /* from blocks*/ ... u16 BlockType;ThisBlockInstanceID; /* to blocks*/ ... ) Where, PkfID= {PkfSID | PkfGID[M]}. If the requested PkfID is a group PkfGID, the format is: ConnectionStateResponse( u16 FE-ID; Reserved; u64 PkfGID[M:N]; /*the PkfGID name*/ u16 FromBlockNumber; ToBlockNumber; u16 BlockType; ThisBlockInstanceID; /*first from block*/ u16 PkfGBranchNumber;16bitsReserved; (list of PkfGID branches connected to this block) ... Wang Expires Feb. 2004 [Page 19] Internet Draft Topology Representation for ForCES Aug. 2003 u16 BlockType;ThisBlockInstanceID; /*first to block*/ u16 PkfGBranchNumber;16bitsReserved; (list of PkfGID branches connected to this block) ... /*for other blocks connected*/ ) 5. Block attribute representation using PkfIDs Every FE block is associated with some attributes, which SHOULD be configured by CEs according to required IP packet processing functions to be implemented by the block. After the FE block topology is represented by PkfIDs, all the block ingresses and egresses in the topology can be recognized by the connected PkfIDs. A block can then operate its ingresses and egresses based on the connected PkfIDs, so attributes associated with the block can also use these PkfIDs to represent their functions. This also implies that after PkfIDs are used, we do not care about ingress and egress port numbers any more. Let us take a classifier block as an example. The classifier has two ingresses and four egresses, and has been marked with PkfSIDs as shown in Figure 11. +-----+ PkfSID3 | |---------> | | PkfSID4 PkfSID1 | |---------> ------->| | PkfSID5 PkfSID2 | |---------> ------->| | PkfSID6 | |---------> | | PkfSID7 | |---------> +-----+ Classifier block Figure 11. An FE classifier block marked with PkfSIDs Note that this classifier allows more than one input by including a Multiplexor block in it [RFC3290]. Attributes for classifiers can be represented by filtering rules. For instance, if we need the classifier in Figure 11 to classify packets based on DSCP field to support Diffserv, we may set classifier rules, which is expressed in text as follows: Wang Expires Feb. 2004 [Page 20] Internet Draft Topology Representation for ForCES Aug. 2003 Rule1: if((packet from PkfSID1)&&(DSCP field =='101010')), then (put packet to PkfSID3). Rule2: if((packet from PkfSID1 or PkfSID2)&&(DSCP field == any)), then (put packet to PkfSID7). We may have other rules like: Rule3: if((packet from PkfSID2)&& (IPv4 Src Addr='172.31.8.1/32')&& (IPv4 Dest Addr='172.31.3.X/24')&& (TCP Dest Port='5003'), then (drop packet). To manipulate ingresses or egresses in groups, we can also use PkfGIDs, then Figure 11 can be marked as in Figure 12. +-----+ | | PkfGID1[1:2]| | PkfGID2[1:5] -------\| |---------\ -------/| |---------/ | | | | +-----+ Classifier block Figure 12. An FE classifier block marked with PkfGIDs Then we can re-describe Rule2 as follows: Rule2: if((packet from PkfGID1[1:2])&&(DSCP field == any)), then (put packet to PkfGID2[5]). It is not difficult for a ForCES protocol message to describe above rules in message format. Some tags may be needed to represent the rule actions such as 'PUT' and 'DROP'. We will not discuss this more for it is out of scope of this document. The above rule attributes can be manipulated on the fly during FE runtime by ForCES protocol messages, to support ForCES dynamic configuration. Wang Expires Feb. 2004 [Page 21] Internet Draft Topology Representation for ForCES Aug. 2003 Generally, a more universal block, which we call a match block, may be defined in ForCES FE model for ForCES protocol to unify operations of blocks like classifier, filter, routing(forwarding) engine, and even dropper. A match block is shown in Figure 13. - - - - - - - - - - | match block | +------------+ | | | | | rule base | | | | | +------------+ | | | | \ / +------------+ | -------->| |-------> -------->| matching |-------> ... | |.... -------->| |-------> | +------------+ | - - - - - - - - - - Figure 13. A match block This block is composed of a rule base and a matching mechanism. It just does pattern matching to packets from inputs according to rules in the rule base and outputs the packets to specific egresses according to the rule's action. Multi-inputs can be used, and port operations can be based on the assigned PkfIDs. By using this kind of match block, ForCES protocol can unify its ways to manipulate attributes. Attributes can be abstracted as rules, and the rules can even have same uniform data format. What ForCES protocol should do is to add rules, delete rules, modify rules,etc. Note that it does not mean the implementation in FEs for a match block should also have uniform architecture. Based on the match block different functionality, FE may choose to use different implementations. For instance, a match block for a classifier or a forwarding engine may be implemented by hardware, while a filter or a dropper can just be implemented by codes. Therefore a tag is needed in a match block attribute to indicate its different function. The purpose for use of such an abstracted match block is only for easy and uniform manipulation for ForCES protocol. Actually this is out of scope of this document, we will not discuss any more on this topic. 6. FE topology representation using PkfIDs Wang Expires Feb. 2004 [Page 22] Internet Draft Topology Representation for ForCES Aug. 2003 According to ForCES requirements and ForCES framework, an FE topology in a ForCES NE SHOULD be reported to CEs from FEs during FE association establishment phase. Because it is still under discussion on if FE topology should be configurable or not by CEs, we only present how an FE topology information can be represented and reported from FEs to CEs by use of PkfIDs. But if needed, to setup FE topology is also possible based on PkfIDs. Similar to using PkfIDs to represent an FE block topology, first we need to mark the FE topology with PkfIDs. Taking FE topology in Figure 5 as an example, we mark the FE topology as in Figure 14. PkfSID1 +---------+ PkfSID3 +---------+ | |<---------->| | PkfSID7 <------>| FE1 |PkfSID4 | FE3 |<------> | |<--- --->| | +---------+ \ / +---------+ PkfSID5\/ PkfSID2 +---------+ /\ +---------+ | |<---/ \--->| | PkfSID8 <------>| FE2 | PkfSID6 | FE4 |<------> | |<---------->| | +---------+ +---------+ Figure 14. An example of an FE topology Usually it is enough to represent FE topology just by using PkfSIDs, for FE topology has much less connections compared with FE block topology. Note that in FE topology, connections are usually port links that are mostly bi-directional, so we omit the direction information in the representation. Also note that, different from FE block topology, a port address SHOULD be explicitly presented along with the PkfIDs for FE topology representation [FACT], because the ports in FE topology have been physically assigned, while in FE block topology, a PkfID represented block port is only a dynamic memory address which FE codes have freedom to arrange. The FE port address can be an IP address, an MAC address or other format of addresses. A tag is needed in the address format to indicate the address format. Because currently we do not require CEs to configure FE topology, FE topology is usually constructed at FE side either manually or automatically by FE automatic discovery of each other. To represent FE topology using PkfIDs, it is REQUIRED topology be marked with PkfIDs from FE side either manually or automatically by FE codes. After FE topology is marked with PkfIDs, FEs are ready to report their topology to CEs by sending a ForCES FE topology report message. Wang Expires Feb. 2004 [Page 23] Internet Draft Topology Representation for ForCES Aug. 2003 The message will be sent either when CE sends an FE topology request or when the FE topology has been changed such as an FE has left or newly joined the FE topology. The FE topology report message is defined with following format: FEtopologyReprot( _u16 FE-Number; Reserved; _u16 FE-ID; FE-PortNumber; /*first FE*/ _u64 PortAddr; /*first port in first FE*/ _u32 PkfSID; _u64 PortAddr; /*second port in first FE*/ _u32 PkfSID; ... _u16 FE-ID; FE-PortNumber; /*second FE*/ _u64 PortAddr; /*first port in second FE*/ _u32 PkfSID; _u64 PortAddr; /*second port in second FE*/ _u32 PkfSID; ... ... /* for other FEs */ ) Where, FE-Number: number of FEs in this FE topology; FE-ID: the specific FE identifier; FE-PortNumber: the FE number of ports that have been marked withPkfIDs; PortAddr: the address assigned to the specific FE port; PkfSID: the PkfIDs assigned to the connection linked to this port. In the message format, the order of FEs and the order of individual ports in an FE do not matter. As an example, we show the FE topology report message for Figure 14 as below: FEtopologyReport( _u16 FE-Number(=4); Reserved; _u16 FE-ID(=FE1); FE-PortNumber(=3); /*for FE1*/ _u64 PortAddr; _u32 PkfSID1; _u64 PortAddr; _u32 PkfSID3; _u64 PortAddr; Wang Expires Feb. 2004 [Page 24] Internet Draft Topology Representation for ForCES Aug. 2003 _u32 PkfSID4; _u16 FE-ID(=FE2); FE-PortNumber(=3); /*for FE2*/ _u64 PortAddr; _u32 PkfSID2; _u64 PortAddr; _u32 PkfSID5; _u64 PortAddr; _u32 PkfSID6; _u16 FE-ID(=FE3); FE-PortNumber(=3); /*for FE3*/ _u64 PortAddr; _u32 PkfSID3; _u64 PortAddr; _u32 PkfSID4; _u64 PortAddr; _u32 PkfSID7; _u16 FE-ID(=FE4); FE-PortNumber(=3); /*for FE4*/ _u64 PortAddr; _u32 PkfSID4; _u64 PortAddr; _u32 PkfSID6; _u64 PortAddr; _u32 PkfSID8; ) 7. Security Considerations This document only introduces topology representation approaches that need to be associated with an actual protocol like ForCES protocol. The security issues SHOULD be addressed in the associated protocols. 8. References 8.1. Normative References [FORCES-REQ] H. Khosravi, T. Anderson, "Requirements for Separation of IP Control and Forwarding", , July 2003. [FORCES-FRM] L. Yang, et. al, "Forwarding and Control Element Separation (ForCES) Framework", , July 2003. [GRMP-WANG] W. Wang, "A Control Scheme and Management Protocol for Open Programmable QoS IP Routers", Proceedings of SCI 2003, July 2003. Wang Expires Feb. 2004 [Page 25] Internet Draft Topology Representation for ForCES Aug. 2003 [RFC3290] Y. Bernet, et. al., "An Informal Management Model for Diffserv Routers", RFC3290,May 2002. 8.2. Informative References [MODEL-YANG] L. Yang, et al., "ForCES Forwarding Element Functional Model", work in progress, . [FACT] A. Audu, et al., "ForwArding and Control ElemenT protocol (FACT)", work in progress, June 2003, . [NL2-SALIM] J. Salim, et al., "Netlink2 as ForCES Protocol", work in progress, June 2003, . [QDD-IM] B. Moore, et al., "Information Model for Describing Network Device QoS Datapath Mechanisms", work in progress, May 2003, , 9. Acknowledgments The authors would like to thank Lily L. Yang for her valuable suggestion, which makes this document available, and her help during writing of this document. 10. Authors' Addresses Weiming Wang Hangzhou University of Commerce 149 Jiaogong Road Hangzhou, 310035, P.R.China Phone: +86-571-88057712 Email: wangwm@hzcnc.com; wmwang@mail.hzic.edu.cn Wang Expires Feb. 2004 [Page 26]