[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   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", <draft-ietf-forces-require-ments-
   10.txt>, July 2003.

   [FORCES-FRM] L. Yang, et. al, "Forwarding and Control Element
   Separation (ForCES) Framework", <draft-ietf-forces-framework-06.txt>,
   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, <draft-yang-forces-model-02.txt>.

   [FACT] A. Audu, et al., "ForwArding and Control ElemenT protocol
   (FACT)", work in progress, June 2003, <draft-gopal-forces-fact-
   04.txt>.

   [NL2-SALIM] J. Salim, et al., "Netlink2 as ForCES Protocol", work in
   progress, June 2003, <draft-jhsrha-forces-netlink2-01.txt>.

   [QDD-IM] B. Moore, et al., "Information Model for Describing Network
   Device QoS Datapath Mechanisms", work in progress, May 2003, <draft-
   ietf-policy-qos-device-info-model-10.txt>,

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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/