Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5810

Forwarding and Control Element Separation (ForCES) Protocol Specification

Pages: 124
Proposed Standard
Errata
Updated by:  71217391
Part 4 of 5 – Pages 56 to 86
First   Prev   Next

Top   ToC   RFC5810 - Page 56   prevText

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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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   ToC   RFC5810 - 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 page on part 5)

Next Section