tech-invite   World Map     

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

RFC 5810

 
 
 

Forwarding and Control Element Separation (ForCES) Protocol Specification

Part 4 of 5, p. 56 to 86
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 56 
7.2.  Protocol Encoding Visualization

   The figure below shows a general layout of the PL PDU.  A main header
   is followed by one or more LFB selections each of which may contain
   one or more operations.

Top      Up      ToC       Page 57 
   main hdr (Config in this case)
        |
        |
        +--- T = LFBselect
        |        |
        |        +-- LFBCLASSID
        |        |
        |        |
        |        +-- LFBInstance
        |        |
        |        +-- T = SET
        |        |   |
        |        |   +--  // one or more path targets
        |        |        // with their data here to be added
        |        |
        |        +-- T  = DEL
        |        .   |
        |        .   +--  // one or more path targets to be deleted
        |
        |
        +--- T = LFBselect
        |        |
        |        +-- LFBCLASSID
        |        |
        |        |
        |        +-- LFBInstance
        |        |
        |        + -- T= SET
        |        |    .
        |        |    .
        |        + -- T= DEL
        |        |    .
        |        |    .
        |        |
        |        + -- T= SET
        |        |    .
        |        |    .
        |
        |
        +--- T = LFBselect
                |
                +-- LFBCLASSID
                |
                +-- LFBInstance
                .
                .
                .
                     Figure 21: PL PDU Logical Layout

Top      Up      ToC       Page 58 
   The figure below shows a more detailed example of the general layout
   of the operation within a targeted LFB selection.  The idea is to
   show the different nesting levels a path could take to get to the
   target path.

        T = SET
        |  |
        |  +- T = Path-data
        |       |
        |       + -- flags
        |       + -- IDCount
        |       + -- IDs
        |       |
        |       +- T = Path-data
        |          |
        |          + -- flags
        |          + -- IDCount
        |          + -- IDs
        |          |
        |          +- T = Path-data
        |             |
        |             + -- flags
        |             + -- IDCount
        |             + -- IDs
        |             + -- T = KEYINFO-TLV
        |             |    + -- KEY_ID
        |             |    + -- KEY_DATA
        |             |
        |             + -- T = FULLDATA-TLV
        |                  + -- data
        |
        |
        T = SET
        |  |
        |  +- T = Path-data
        |  |  |
        |  |  + -- flags
        |  |  + -- IDCount
        |  |  + -- IDs
        |  |  |
        |  |  + -- T = FULLDATA-TLV
        |  |          + -- data
        |  +- T = Path-data
        |     |

Top      Up      ToC       Page 59 
        |     + -- flags
        |     + -- IDCount
        |     + -- IDs
        |     |
        |     + -- T = FULLDATA-TLV
        |             + -- data
        T = DEL
           |
           +- T = Path-data
                |
                + -- flags
                + -- IDCount
                + -- IDs
                |
                +- T = Path-data
                   |
                   + -- flags
                   + -- IDCount
                   + -- IDs
                   |
                   +- T = Path-data
                      |
                      + -- flags
                      + -- IDCount
                      + -- IDs
                      + -- T = KEYINFO-TLV
                      |    + -- KEY_ID
                      |    + -- KEY_DATA
                      +- T = Path-data
                           |
                           + -- flags
                           + -- IDCount
                           + -- IDs


                    Figure 22: Sample Operation Layout

   Appendix D shows a more concise set of use cases on how the data
   encoding is done.

7.3.  Core ForCES LFBs

   There are two LFBs that are used to control the operation of the
   ForCES protocol and to interact with FEs and CEs:

   o  FE Protocol LFB

Top      Up      ToC       Page 60 
   o  FE Object LFB

   Although these LFBs have the same form and interface as other LFBs,
   they are special in many respects.  They have fixed well-known LFB
   Class and Instance IDs.  They are statically defined (no dynamic
   instantiation allowed), and their status cannot be changed by the
   protocol: any operation to change the state of such LFBs (for
   instance, in order to disable the LFB) MUST result in an error.
   Moreover, these LFBs MUST exist before the first ForCES message can
   be sent or received.  All components in these LFBs MUST have pre-
   defined default values.  Finally, these LFBs do not have input or
   output ports and do not integrate into the intra-FE LFB topology.

7.3.1.  FE Protocol LFB

   The FE Protocol LFB is a logical entity in each FE that is used to
   control the ForCES protocol.  The FE Protocol LFB Class ID is
   assigned the value 0x2.  The FE Protocol LFB Instance ID is assigned
   the value 0x1.  There MUST be one and only one instance of the FE
   Protocol LFB in an FE.  The values of the components in the FE
   Protocol LFB have pre-defined default values that are specified here.
   Unless explicit changes are made to these values using Config
   messages from the CE, these default values MUST be used for correct
   operation of the protocol.

   The formal definition of the FE Protocol Object LFB can be found in
   Appendix B.

7.3.1.1.  FE Protocol Capabilities

   FE Protocol capabilities are read-only.

7.3.1.1.1.  SupportableVersions

   ForCES protocol version(s) supported by the FE.

7.3.1.1.2.  FE Protocol Components

   FE Protocol components (can be read and set).

7.3.1.1.2.1.  CurrentRunningVersion

   Current running version of the ForCES protocol.

Top      Up      ToC       Page 61 
7.3.1.1.2.2.  FEID

   FE unicast ID.

7.3.1.1.2.3.  MulticastFEIDs

   FE multicast ID(s) list - This is a list of multicast IDs to which
   the FE belongs.  These IDs are configured by the CE.

7.3.1.1.2.4.  CEHBPolicy

   CE heartbeat policy - This policy, along with the parameter 'CE
   Heartbeat Dead Interval (CE HDI)' as described below, defines the
   operating parameters for the FE to check the CE liveness.  The policy
   values with meanings are listed as follows:

   o  0 (default) - This policy specifies that the CE will send a
      Heartbeat message to the FE(s) whenever the CE reaches a time
      interval within which no other PL messages were sent from the CE
      to the FE(s); refer to Section 4.3.3 and Section 7.10 for details.
      The CE HDI component as described below is tied to this policy.

   o  1 - The CE will not generate any HB messages.  This actually means
      that the CE does not want the FE to check the CE liveness.

   o  Others - Reserved.

7.3.1.1.2.5.  CEHDI

   CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses
   to check the CE liveness.  If FE has not received any messages from
   CE within this time interval, FE deduces lost connectivity, which
   implies that the CE is dead or the association to the CE is lost.
   Default value is 30 s.

7.3.1.1.2.6.  FEHBPolicy

   FE heartbeat policy - This policy, along with the parameter 'FE
   Heartbeat Interval (FE HI)', defines the operating parameters for how
   the FE should behave so that the CE can deduce its liveness.  The
   policy values and the meanings are:

   o  0 (default) - The FE should not generate any Heartbeat messages.
      In this scenario, the CE is responsible for checking FE liveness
      by setting the PL header ACK flag of the message it sends to
      AlwaysACK.  The FE responds to the CE whenever the CE sends such
      Heartbeat Request messages.  Refer to Section 7.10 and
      Section 4.3.3 for details.

Top      Up      ToC       Page 62 
   o  1 - This policy specifies that the FE MUST actively send a
      Heartbeat message if it reaches the time interval assigned by the
      FE HI as long as no other messages were sent from the FE to the CE
      during that interval as described in Section 4.3.3.

   o  Others - Reserved.

7.3.1.1.2.7.  FEHI

   FE Heartbeat Interval (FE HI) - The time interval the FE should use
   to send HB as long as no other messages were sent from the FE to the
   CE during that interval as described in Section 4.3.3.  The default
   value for an FE HI is 500 ms.

7.3.1.1.2.8.  CEID

   Primary CEID - The CEID with which the FE is associated.

7.3.1.1.2.9.  LastCEID

   Last Primary CEID - The CEID of the last CE with which the FE
   associated.  This CE ID is reported to the new Primary CEID.

7.3.1.1.2.10.  BackupCEs

   The list of backup CEs an FE can use as backups.  Refer to Section 8
   for details.

7.3.1.1.2.11.  CEFailoverPolicy

   CE failover policy - This specifies the behavior of the FE when the
   association with the CE is lost.  There is a very tight relation
   between CE failover policy and Section 7.3.1.1.2.8,
   Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8.  When an
   association is lost, depending on configuration, one of the policies
   listed below is activated.

   o  0 (default) - The FE should stop functioning immediately and
      transition to FE OperDisable.

   o  1 - The FE should continue running and do what it can even without
      an associated CE.  This basically requires that the FE support CE
      Graceful restart (and defines such support in its capabilities).
      If the CEFTI expires before the FE re-associates with either the
      primary CEID (Section 7.3.1.1.2.8) or one of possibly several
      backup CEs (Section 7.3.1.1.2.10), the FE will go operationally
      down.

Top      Up      ToC       Page 63 
   o  Others - Reserved.

7.3.1.1.2.12.  CEFTI

   CE Failover Timeout Interval (CEFTI) - The time interval associated
   with the CE failover policy case '0' and '1'.  The default value is
   set to 300 seconds.  Note that it is advisable to set the CEFTI value
   much higher than the CE Heartbeat Dead Interval (CE HDI) since the
   effect of expiring this parameter is devastating to the operation of
   the FE.

7.3.1.1.2.13.  FERestartPolicy

   FE restart policy - This specifies the behavior of the FE during an
   FE restart.  The restart may be from an FE failure or other reasons
   that have made the FE down and then need to restart.  The values are
   defined as follows:

   o  0(default)- Restart the FE from scratch.  In this case, the FE
      should start from the pre-association phase.

   o  Others - Reserved for future use.

7.3.2.  FE Object LFB

   The FE Object LFB is a logical entity in each FE and contains
   components relative to the FE itself, and not to the operation of the
   ForCES protocol.

   The formal definition of the FE Object LFB can be found in [RFC5812].
   The model captures the high-level properties of the FE that the CE
   needs to know to begin working with the FE.  The class ID for this
   LFB class is also assigned in [RFC5812].  The singular instance of
   this class will always exist, and will always have instance ID 0x1
   within its class.  It is common, although not mandatory, for a CE to
   fetch much of the component and capability information from this LFB
   instance when the CE begins controlling the operation of the FE.

7.4.  Semantics of Message Direction

   Recall: The PL provides a master(CE)-slave(FE) relationship.  The
   LFBs reside at the FE and are controlled by CE.

   When messages go from the CE, the LFB selector (class and instance)
   refers to the destination LFB selection that resides in the FE.

   When messages go from the FE to the CE, the LFB selector (class and
   instance) refers to the source LFB selection that resides in the FE.

Top      Up      ToC       Page 64 
7.5.  Association Messages

   The ForCES Association messages are used to establish and tear down
   associations between FEs and CEs.

7.5.1.  Association Setup Message

   This message is sent by the FE to the CE to set up a ForCES
   association between them.

   Message transfer direction:
      FE to CE

   Message header:
      The Message Type in the header is set to MessageType=
      'AssociationSetup'.  The ACK flag in the header MUST be ignored,
      and the Association Setup message always expects to get a response
      from the message receiver (CE), whether or not the setup is
      successful.  The correlator field in the header is set, so that FE
      can correlate the response coming back from the CE correctly.  The
      FE may set the source ID to 0 in the header to request that the CE
      should assign an FE ID for the FE in the Setup Response message.

   Message body:
      The Association Setup message body optionally consists of zero,
      one, or two LFBselect TLVs, as described in Section 7.1.5.  The
      Association Setup message only operates on the FE Object and FE
      Protocol LFBs; therefore, the LFB class ID in the LFBselect TLV
      only points to these two kinds of LFBs.

      The OPER-TLV in the LFBselect TLV is defined as a 'REPORT'
      operation.  More than one component may be announced in this
      message using the REPORT operation to let the FE declare its
      configuration parameters in an unsolicited manner.  These may
      contain components suggesting values such as the FE HB Interval or
      the FEID.  The OPER-TLV used is defined below.

Top      Up      ToC       Page 65 
   OPER-TLV for Association Setup:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type = REPORT              |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    PATH-DATA-TLV for REPORT                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 23: OPER-TLV

   Type:
      Only one operation type is defined for the Association Setup
      message:

      Type = "REPORT" - This type of operation is for the FE to report
             something to the CE.

   PATH-DATA-TLV for REPORT:
      This is generically a PATH-DATA-TLV format that has been defined
      in Section 7 in the PATH-DATA BNF definition.  The PATH-DATA-TLV
      for the REPORT operation MAY contain FULLDATA-TLV(s) but SHALL NOT
      contain any RESULT-TLV in the data format.  The RESULT-TLV is
      defined in Section 7.1.7 and the FULLDATA-TLV is defined in
      Section 7.1.8.

Top      Up      ToC       Page 66 
   To better illustrate the above PDU format, a tree structure for the
   format is shown below:

   main hdr (type =  Association Setup)
        |
        |
        +--- T = LFBselect
        |        |
        |        +-- LFBCLASSID = FE object
        |        |
        |        |
        |        +-- LFBInstance = 0x1
        |
        +--- T = LFBselect
                 |
                 +-- LFBCLASSID = FE Protocol object
                 |
                 |
                 +-- LFBInstance = 0x1
                       |
                       +---OPER-TLV = REPORT
                           |
                           +-- Path-data to one or more components

            Figure 24: PDU Format for Association Setup Message

7.5.2.  Association Setup Response Message

   This message is sent by the CE to the FE in response to the Setup
   message.  It indicates to the FE whether or not the setup is
   successful, i.e., whether an association is established.

   Message transfer direction:

   CE to FE

   Message header:

   The Message Type in the header is set to MessageType=
   'AssociationSetupResponse'.  The ACK flag in the header MUST be
   ignored, and the Setup Response message never expects to get any more
   responses from the message receiver (FE).  The destination ID in the
   header will be set to the source ID in the corresponding Association
   Setup message, unless that source ID was 0.  If the corresponding
   source ID was 0, then the CE will assign an FE ID value and use that
   value for the destination ID.

Top      Up      ToC       Page 67 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = ASRresult       |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Association Setup Result                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 25: ASResult OPER-TLV

   Type (16 bits):

   The type of the TLV is "ASResult".

   Length (16 bits):

   Length of the TLV including the T and L fields, in octets.

   Association Setup result (32 bits):

   This indicates whether the Setup message was successful or whether
   the FE request was rejected by the CE.  The defined values are:

       0 = success

       1 = FE ID invalid

       2 = permission denied

Top      Up      ToC       Page 68 
   To better illustrate the above PDU format, a tree structure for the
   format is shown below:

   main hdr (type =  Association Setup Response)
    |
    |
    +--- T = ASResult-TLV

      Figure 26: PDU Format for Association Setup Response Message

7.5.3.  Association Teardown Message

   This message can be sent by the FE or CE to any ForCES element to end
   its ForCES association with that element.

   Message transfer direction:

   CE to FE, or FE to CE (or CE to CE)

   Message Header:

   The Message Type in the header is set to MessageType=
   "AssociationTeardown".  The ACK flag MUST be ignored.  The correlator
   field in the header MUST be set to zero and MUST be ignored by the
   receiver.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = ASTreason       |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Teardown Reason                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 27: ASTreason-TLV

   Type (16 bits):

   The type of the TLV is "ASTreason".

   Length (16 bits):

   Length of the TLV including the T and L fields, in octets.

   Teardown reason (32 bits):

   This indicates the reason why the association is being terminated.
   Several reason codes are defined as follows.

Top      Up      ToC       Page 69 
       0 - normal teardown by administrator

       1 - error - loss of heartbeats

       2 - error - out of bandwidth

       3 - error - out of memory

       4 - error - application crash

       255 - error - other or unspecified

   To better illustrate the above PDU format, a tree structure for the
   format is shown below:

   main hdr (type =  Association Teardown)
    |
    |
    +--- T = ASTreason-TLV

      Figure 28: PDU Format for Association Teardown Message

7.6.  Configuration Messages

   The ForCES Configuration messages are used by CE to configure the FEs
   in a ForCES NE and report the results back to the CE.

7.6.1.  Config Message

   This message is sent by the CE to the FE to configure LFB components
   in the FE.  This message is also used by the CE to subscribe/
   unsubscribe to LFB events.

   As usual, a Config message is composed of a common header followed by
   a message body that consists of one or more TLV data formats.
   Detailed description of the message is as follows:

   Message transfer direction:

   CE to FE

   Message header:

   The Message Type in the header is set to MessageType= 'Config'.  The
   ACK flag in the header can be set to any value defined in
   Section 6.1, to indicate whether or not a response from the FE is
   expected by the message.

Top      Up      ToC       Page 70 
   OPER-TLV for Config:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Type                 |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        PATH-DATA-TLV                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 29: OPER-TLV for Config

   Type:

   The operation type for Config message.  Two types of operations for
   the Config message are defined:

       Type = "SET" - This operation is to set LFB components

       Type = "SET-PROP" - This operation is to set LFB component
              properties.

       Type = "DEL" - This operation is to delete some LFB components.

       Type = "COMMIT" - This operation is sent to the FE to commit in a
              2pc transaction.  A COMMIT TLV is an empty TLV, i.e., it
              has no "V"alue.  In other words, there is a length of 4
              (which is for the header only).

       Type = "TRCOMP" - This operation is sent to the FE to mark the
              success from an NE perspective of a 2pc transaction.  A
              TRCOMP TLV is an empty TLV, i.e., it has no "V"alue.  In
              other words, there is a length of 4 (which is for the
              header only).

   PATH-DATA-TLV:

   This is generically a PATH-DATA-TLV format that has been defined in
   Section 7 in the PATH-DATA-TLV BNF definition.  The restriction on
   the use of PATH-DATA-TLV for SET/SET-PROP operation is that it MUST
   contain either FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT
   contain any RESULT-TLV.  The restriction on the use of PATH-DATA-TLV
   for DEL operation is it MAY contain FULLDATA-TLV or
   SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV.  The
   RESULT-TLV is defined in Section 7.1.7 and FULLDATA-TLVs and
   SPARSEDATA-TLVs are defined in Section 7.1.8.

Top      Up      ToC       Page 71 
       Note:  For Event subscription, the events will be defined by the
              individual LFBs.

   To better illustrate the above PDU format, a tree structure for the
   format is shown below:

   main hdr (type = Config)
    |
    |
    +--- T = LFBselect
    .        |
    .        +-- LFBCLASSID = target LFB class
    .        |
             |
             +-- LFBInstance = target LFB instance
             |
             |
             +-- T = operation { SET }
             |   |
             |   +--  // one or more path targets
             |      // associated with FULLDATA-TLV or SPARSEDATA-TLV(s)
             |
             +-- T = operation { DEL }
             |   |
             |   +--  // one or more path targets
             |
             +-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV
                      .
                      .

              Figure 30: PDU Format for Configuration Message

7.6.2.  Config Response Message

   This message is sent by the FE to the CE in response to the Config
   message.  It indicates whether or not the Config was successful on
   the FE and also gives a detailed response regarding the configuration
   result of each component.

   Message transfer direction:

   FE to CE

Top      Up      ToC       Page 72 
   Message header:

   The Message Type in the header is set to MessageType= 'Config
   Response'.  The ACK flag in the header is always ignored, and the
   Config Response message never expects to get any further response
   from the message receiver (CE).

   OPER-TLV for Config Response:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Type                 |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        PATH-DATA-TLV                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 31: OPER-TLV for Config Response

   Type:
          The operation type for Config Response message.  Two types of
          operations for the Config Response message are defined:

       Type = "SET-RESPONSE" - This operation is for the response of the
              SET operation of LFB components.

       Type = "SET-PROP-RESPONSE" - This operation is for the response
              of the SET-PROP operation of LFB component properties.

       Type = "DEL-RESPONSE" - This operation is for the response of the
              DELETE operation of LFB components.

       Type = "COMMIT-RESPONSE" - This operation is sent to the CE to
              confirm a commit success in a 2pc transaction.  A
              COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating
              success or failure.

   PATH-DATA-TLV:

   This is generically a PATH-DATA-TLV format that has been defined in
   Section 7 in the PATH-DATA-TLV BNF definition.  The restriction on
   the use of PATH-DATA-TLV for SET-RESPONSE operation is that it MUST
   contain RESULT-TLV(s).  The restriction on the use of PATH-DATA-TLV
   for DEL-RESPONSE operation is it also MUST contain RESULT-TLV(s).
   The RESULT-TLV is defined in Section 7.1.7.

Top      Up      ToC       Page 73 
   To better illustrate the above PDU format, a tree structure for the
   format is shown below:

    main hdr (type = ConfigResponse)
     |
     |
     +--- T = LFBselect
     .        |
     .        +-- LFBCLASSID = target LFB class
     .        |
              |
              +-- LFBInstance = target LFB instance
              |
              |
              +-- T = operation { SET-RESPONSE }
              |   |
              |   +--  // one or more path targets
              |        // associated with FULL or SPARSEDATA-TLV(s)
              |
              +-- T = operation { DEL-RESPONSE }
              |   |
              |   +--  // one or more path targets
              |
              +-- T = operation { COMMIT-RESPONSE }
              |           |
              |           +--  RESULT-TLV

             Figure 32: PDU Format for Config Response Message

7.7.  Query Messages

   The ForCES Query messages are used by the CE to query LFBs in the FE
   for information like LFB components, capabilities, statistics, etc.
   Query messages include the Query message and the Query Response
   message.

7.7.1.  Query Message

   A Query message is composed of a common header and a message body
   that consists of one or more TLV data formats.  Detailed description
   of the message is as follows:

   Message transfer direction:

   from CE to FE

Top      Up      ToC       Page 74 
   Message header:

   The Message Type in the header is set to MessageType= 'Query'.  The
   ACK flag in the header is always ignored, and a full response for a
   Query message is always expected.  The Correlator field in the header
   is set, so that the CE can locate the response back from FE
   correctly.

   OPER-TLV for Query:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type = GET/GET-PROP        |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    PATH-DATA-TLV for GET/GET-PROP             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 33: TLV for Query

   Type:

   The operation type for query.  Two operation types are defined:

       Type = "GET" - This operation is to request to get LFB
              components.

       Type = "GET-PROP" - This operation is to request to get LFB
              component properties.

   PATH-DATA-TLV for GET/GET-PROP:

   This is generically a PATH-DATA-TLV format that has been defined in
   Section 7 in the PATH-DATA-TLV BNF definition.  The restriction on
   the use of PATH-DATA-TLV for GET/GET-PROP operation is it MUST NOT
   contain any SPARSEDATA-TLV or FULLDATA- TLV and RESULT-TLV in the
   data format.

Top      Up      ToC       Page 75 
   To better illustrate the above PDU format, a tree structure for the
   format is shown below:

   main hdr (type = Query)
    |
    |
    +--- T = LFBselect
    .        |
    .        +-- LFBCLASSID = target LFB class
    .        |
             |
             +-- LFBInstance = target LFB instance
             |
             |
             +-- T = operation { GET }
             |   |
             |   +--  // one or more path targets
             |
             +-- T = operation { GET }
             .   |
             .   +--  // one or more path targets
             .

                  Figure 34: PDU Format for Query Message

7.7.2.  Query Response Message

   When receiving a Query message, the receiver should process the
   message and come up with a query result.  The receiver sends the
   query result back to the message sender by use of the Query Response
   message.  The query result can be the information being queried if
   the query operation is successful, or can also be error codes if the
   query operation fails, indicating the reasons for the failure.

   A Query Response message is also composed of a common header and a
   message body consisting of one or more TLVs describing the query
   result.  Detailed description of the message is as follows:

   Message transfer direction:

   from FE to CE

   Message header:

   The Message Type in the header is set to MessageType=
   'QueryResponse'.  The ACK flag in the header is ignored.  As a
   response itself, the message does not expect a further response.

Top      Up      ToC       Page 76 
   OPER-TLV for Query Response:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Type = GET-RESPONSE/GET-PROP-RESPONSE|    Length               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 35: TLV for Query Response

   Type:

   The operation type for query response.  One operation type is
   defined:

       Type = "GET-RESPONSE" - This operation is for the response of the
              GET operation of LFB components.

       Type = "GET-PROP-RESPONSE" - This operation is for the response
              of the GET-PROP operation of LFB components.

   PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE:

   This is generically a PATH-DATA-TLV format that has been defined in
   Section 7 in the PATH-DATA-TLV BNF definition.  The PATH-DATA- TLV
   for the GET-RESPONSE operation MAY contain SPARSEDATA-TLV,
   FULLDATA-TLV, and/or RESULT-TLV(s) in the data encoding.  The
   RESULT-TLV is defined in Section 7.1.7 and the SPARSEDATA-TLVs and
   FULLDATA-TLVs are defined in Section 7.1.8.

Top      Up      ToC       Page 77 
   To better illustrate the above PDU format, a tree structure for the
   format is shown below:

   main hdr (type = QueryResponse)
     |
     |
     +--- T = LFBselect
     .        |
     .        +-- LFBCLASSID = target LFB class
     .        |
              |
              +-- LFBInstance = target LFB instance
              |
              |
              +-- T = operation { GET-RESPONSE }
              |   |
              |   +--  // one or more path targets
              |
              +-- T = operation { GET-PROP-RESPONSE }
              .   |
              .   +--  // one or more path targets
              .

             Figure 36: PDU Format for Query Response Message

7.8.  Event Notification Message

   Event Notification message is used by the FE to asynchronously notify
   the CE of events that happen in the FE.

   All events that can be generated in an FE are subscribable by the CE.
   The CE can subscribe to an event via a Config message with the SET-
   PROP operation, where the included path specifies the event, as
   defined by the LFB Library and described by the FE Model.

   As usual, an Event Notification message is composed of a common
   header and a message body that consists of one or more TLV data
   formats.  Detailed description of the message is as follows:

   Message transfer direction:

   FE to CE

Top      Up      ToC       Page 78 
   Message header:

   The Message Type in the message header is set to
   MessageType = 'EventNotification'.  The ACK flag in the header MUST
   be ignored by the CE, and the Event Notification message does not
   expect any response from the receiver.

   OPER-TLV for Event Notification:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = REPORT              |               Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    PATH-DATA-TLV for REPORT                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 37: TLV for Event Notification

   Type:

   Only one operation type is defined for the Event Notification
   message:

      Type = "REPORT" - This type of operation is for the FE to report
             something to the CE.

   PATH-DATA-TLV for REPORT:

   This is generically a PATH-DATA-TLV format that has been defined in
   Section 7 in the PATH-DATA-TLV BNF definition.  The PATH-DATA- TLV
   for the REPORT operation MAY contain FULLDATA-TLV or
   SPARSEDATA-TLV(s) but MUST NOT contain any RESULT-TLV in the data
   format.

Top      Up      ToC       Page 79 
   To better illustrate the above PDU format, a tree structure for the
   format is shown below:

   main hdr (type = Event Notification)
     |
     |
     +--- T = LFBselect
                |
                +-- LFBCLASSID = target LFB class
                |
                |
                +-- LFBInstance = target LFB instance
                |
                |
                +-- T = operation { REPORT }
                |   |
                |   +--  // one or more path targets
                |        // associated with FULL/SPARSE DATA TLV(s)
                +-- T = operation { REPORT }
                .   |
                .   +--  // one or more path targets
                .        // associated with FULL/SPARSE DATA TLV(s)

           Figure 38: PDU Format for Event Notification Message

7.9.  Packet Redirect Message

   A Packet Redirect message is used to transfer data packets between
   the CE and FE.  Usually, these data packets are control packets, but
   they may be just data path packets that need further (exception or
   high-touch) processing.  It is also feasible that this message
   carries no data packets and rather just meta data.

   The Packet Redirect message data format is formatted as follows:

   Message transfer direction:

   CE to FE or FE to CE

   Message header:

   The Message Type in the header is set to MessageType=
   'PacketRedirect'.

Top      Up      ToC       Page 80 
   Message body:

   This consists of one or more TLVs that contain or describe the packet
   being redirected.  The TLV is specifically a Redirect TLV (with the
   TLV Type="Redirect").  Detailed data format of a Redirect TLV for a
   Packet Redirect message is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = Redirect        |               Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Meta Data TLV                          |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Redirect Data TLV                      |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 39: Redirect_Data TLV

   Meta Data TLV:

   This is a TLV that specifies meta data associated with followed
   redirected data.  The TLV is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = METADATA-TLV        |               Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Meta Data ILV                          |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           ...                                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Meta Data ILV                          |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 40: METADATA-TLV

Top      Up      ToC       Page 81 
   Meta Data ILV:

   This is an Identifier-Length-Value format that is used to describe
   one meta data.  The ILV has the format as:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Meta Data ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Length                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Meta Data Value                        |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 41: Meta Data ILV

   where Meta Data ID is an identifier for the meta data, which is
   statically assigned by the LFB definition.

   Redirect Data TLV:

   This is a TLV describing one packet of data to be directed via the
   redirect operation.  The TLV format is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = REDIRECTDATA-TLV    |               Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Redirected Data                        |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 42: Redirect Data TLV

   Redirected Data:

   This field contains the packet that is to be redirected in network
   byte order.  The packet should be 32 bits aligned as is the data for
   all TLVs.  The meta data infers what kind of packet is carried in
   value field and therefore allows for easy decoding of data
   encapsulated.

Top      Up      ToC       Page 82 
   To better illustrate the above PDU format, a tree structure for the
   format is shown below:

   main hdr (type = PacketRedirect)
           |
           |
           +--- T = Redirect
           .        |
           .        +-- T = METADATA-TLV
                    |          |
                    |          +--  Meta Data ILV
                    |          |
                    |          +--  Meta Data ILV
                    |          .
                    |          .
                    |
                    +-- T = REDIRECTDATA-TLV
                        |
                        +--  // Redirected Data

             Figure 43: PDU Format for Packet Redirect Message

7.10.  Heartbeat Message

   The Heartbeat (HB) message is used for one ForCES element (FE or CE)
   to asynchronously notify one or more other ForCES elements in the
   same ForCES NE on its liveness.  Section 4.3.3 describes the traffic-
   sensitive approach used.

   A Heartbeat message is sent by a ForCES element periodically.  The
   parameterization and policy definition for heartbeats for an FE are
   managed as components of the FE Protocol Object LFB, and can be set
   by CE via a Config message.  The Heartbeat message is a little
   different from other protocol messages in that it is only composed of
   a common header, with the message body left empty.  A detailed
   description of the message is as follows:

   Message transfer direction:

   FE to CE or CE to FE

   Message header:

   The Message Type in the message header is set to MessageType =
   'Heartbeat'.  Section 4.3.3 describes the HB mechanisms used.  The
   ACK flag in the header MUST be set to either 'NoACK' or 'AlwaysACK'
   when the HB is sent.

Top      Up      ToC       Page 83 
       *   When set to 'NoACK', the HB is not soliciting for a response.

       *   When set to 'AlwaysACK', the HB Message sender is always
           expecting a response from its receiver.  According to the HB
           policies defined in Section 7.3.1, only the CE can send such
           an HB message to query FE liveness.  For simplicity and
           because of the minimal nature of the HB message, the response
           to an HB message is another HB message, i.e., no specific HB
           Response message is defined.  Whenever an FE receives an HB
           message marked with 'AlwaysACK' from the CE, the FE MUST send
           an HB message back immediately.  The HB message sent by the
           FE in response to the 'AlwaysACK' MUST modify the source and
           destination IDs so that the ID of the FE is the source ID and
           the CE ID of the sender is the destination ID, and MUST
           change the ACK information to 'NoACK'.  A CE MUST NOT respond
           to an HB message with 'AlwaysACK' set.

       *   When set to anything else other than 'NoACK' or 'AlwaysACK',
           the HB message is treated as if it was a 'NoACK'.

   The correlator field in the HB message header SHOULD be set
   accordingly when a response is expected so that a receiver can
   correlate the response correctly.  The correlator field MAY be
   ignored if no response is expected.

   Message body:

   The message body is empty for the Heartbeat message.

8.  High Availability Support

   The ForCES protocol provides mechanisms for CE redundancy and
   failover, in order to support High Availability as defined in
   [RFC3654].  FE redundancy and FE to FE interaction is currently out
   of scope of this document.  There can be multiple redundant CEs and
   FEs in a ForCES NE.  However, at any one time only one primary CE can
   control the FEs though there can be multiple secondary CEs.  The FE
   and the CE PL are aware of the primary and secondary CEs.  This
   information (primary, secondary CEs) is configured in the FE and in
   the CE PLs during pre-association by the FEM and the CEM
   respectively.  Only the primary CE sends control messages to the FEs.

8.1.  Relation with the FE Protocol

   High Availability parameterization in an FE is driven by configuring
   the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1).
   The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE

Top      Up      ToC       Page 84 
   Heartbeat policy help in detecting connectivity problems between an
   FE and CE.  The CE failover policy defines the reaction on a detected
   failure.

   Figure 44 extends the state machine illustrated in Figure 4 to allow
   for new states that facilitate connection recovery.

       (CE issues Teardown ||    +-----------------+
          Lost association) &&   | Pre-association |
         CE failover policy = 0  | (Association    |
             +------------>-->-->|   in            +<----+
             |                   | progress)       |     |
             |     CE issues     +--------+--------+     |
             |     Association        |                  | CFTI
             |       Setup            V                  | timer
             |     ___________________+                  | expires
             |     |                                     |
             |     V                                     ^
           +-+-----------+                          +-------+-----+
           |             |                          |  Not        |
           |             |  (CE issues Teardown ||  |  Associated |
           |             |    Lost association) &&  |             |
           | Associated  |  CE failover policy = 1  | (May        |
           |             |                          | Continue    |
           |             |---------->------->------>|  Forwarding)|
           |             |                          |             |
           +-------------+                          +-------------+
                ^                                         V
                |                                         |
                |            CE issues                    |
                |            Association                  |
                |            Setup                        |
                +_________________________________________+

                Figure 44: FE State Machine Considering HA

   Section 4.2 describes transitions between the pre-association,
   associated, and not associated states.

   When communication fails between the FE and CE (which can be caused
   by either the CE or link failure but not FE related), either the TML
   on the FE will trigger the FE PL regarding this failure or it will be
   detected using the HB messages between FEs and CEs.  The
   communication failure, regardless of how it is detected, MUST be
   considered as a loss of association between the CE and corresponding
   FE.

Top      Up      ToC       Page 85 
   If the FE's FEPO CE failover policy is configured to mode 0 (the
   default), it will immediately transition to the pre-association
   phase.  This means that if association is again established, all FE
   state will need to be re-established.

   If the FE's FEPO CE failover policy is configured to mode 1, it
   indicates that the FE is capable of HA restart recovery.  In such a
   case, the FE transitions to the not associated state and the CEFTI
   timer is started.  The FE MAY continue to forward packets during this
   state.  It MAY also recycle through any configured secondary CEs in a
   round-robin fashion.  It first adds its primary CE to the tail of
   backup CEs and sets its primary CE to be the first secondary.  It
   then attempts to associate with the CE designated as the new primary
   CE.  If it fails to re-associate with any CE and the CEFTI expires,
   the FE then transitions to the pre-association state.

   If the FE, while in the not associated state, manages to reconnect to
   a new primary CE before CEFTI expires, it transitions to the
   associated state.  Once re-associated, the FE tries to recover any
   state that may have been lost during the not associated state.  How
   the FE achieves this is out of scope for this document.

   Figure 45 below illustrates the ForCES message sequences that the FE
   uses to recover the connection.

         FE                   CE Primary        CE Secondary
         |                       |                    |
         |  Asso Estb,Caps exchg |                    |
       1 |<--------------------->|                    |
         |                       |                    |
         |       All msgs        |                    |
       2 |<--------------------->|                    |
         |                       |                    |
         |                       |                    |
         |                   FAILURE                  |
         |                                            |
         |         Asso Estb,Caps exchange            |
       3 |<------------------------------------------>|
         |                                            |
         |              Event Report (pri CE down)    |
       4 |------------------------------------------->|
         |                                            |
         |                   All Msgs                 |
       5 |<------------------------------------------>|

              Figure 45: CE Failover for Report Primary Mode

Top      Up      ToC       Page 86 
   A CE-to-CE synchronization protocol would be needed to support fast
   failover as well as to address some of the corner cases; however,
   this will not be defined by the ForCES protocol as it is out of scope
   for this specification.

   An explicit message (a Config message setting primary CE component in
   the FE Protocol Object) from the primary CE can also be used to
   change the primary CE for an FE during normal protocol operation.

   Also note that the FEs in a ForCES NE could also use a multicast CE
   ID, i.e., they could be associated with a group of CEs (this assumes
   the use of a CE-CE synchronization protocol, which is out of scope
   for this specification).  In this case, the loss of association would
   mean that communication with the entire multicast group of CEs has
   been lost.  The mechanisms described above will apply for this case
   as well during the loss of association.  If, however, the secondary
   CE was also using the multicast CE ID that was lost, then the FE will
   need to form a new association using a different CE ID.  If the
   capability exists, the FE MAY first attempt to form a new association
   with the original primary CE using a different non-multicast CE ID.

8.2.  Responsibilities for HA

   TML level:

   1.  The TML controls logical connection availability and failover.

   2.  The TML also controls peer HA management.

   At this level, control of all lower layers, for example, transport
   level (such as IP addresses, MAC addresses, etc.) and associated
   links going down are the role of the TML.

   PL level:

   All other functionality, including configuring the HA behavior during
   setup, the CE IDs used to identify primary and secondary CEs,
   protocol messages used to report CE failure (Event Report), Heartbeat
   messages used to detect association failure, messages to change the
   primary CE (Config), and other HA-related operations described
   before, are the PL responsibility.

   To put the two together, if a path to a primary CE is down, the TML
   would take care of failing over to a backup path, if one is
   available.  If the CE is totally unreachable, then the PL would be
   informed and it would take the appropriate actions described earlier.


Next RFC Part