Network Working Group
Internet Engineering Task Force (IETF)                          K. Ogawa
Internet-Draft
Request for Comments: 7121                               NTT Corporation
Updates: 5810 (if approved)                                                 W. M. Wang
Intended status:
Category: Standards Track                  Zhejiang Gongshang University
Expires: June 13, 2014
ISSN: 2070-1721                                            E. Haleplidis
                                                    University of Patras
                                                           J. Hadi Salim
                                                       Mojatatu Networks
                                                       December 10, 2013

                   ForCES Intra-NE
                                                           February 2014

  High Availability
                       draft-ietf-forces-ceha-10 within a Forwarding and Control Element Separation
                        (ForCES) Network Element

Abstract

   This document discusses Control Element (CE) High Availability (HA)
   within a
   ForCES Forwarding and Control Element Separation (ForCES) Network Element.  Additionally
   Element (NE).  Additionally, this document updates [RFC5810] RFC 5810 by
   providing new normative text for the Cold-Standby Cold Standby High
   availability Availability
   mechanism.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 13, 2014.
   http://www.rfc-editor.org/info/rfc7121.

Copyright Notice

   Copyright (c) 2013 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Definitions .  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . .
     1.1.  Quantifying Problem Scope . . . . .   3
     2.1.  Document Scope  . . . . . . . . . . . . . .   4
     1.2.  Definitions . . . . . . .   5
     2.2.  Quantifying Problem Scope . . . . . . . . . . . . . . . .   5
   3.  RFC5810
   2.  RFC 5810 CE HA Framework  . . . . . . . . . . . . . . . . . . .   6
     3.1.   7
     2.1.  RFC 5810 CE HA Support  . . . . . . . . . . . . . . . . .   6
       3.1.1.   7
       2.1.1.  Cold Standby Interaction with the ForCES Protocol . . . .   7
       3.1.2.   8
       2.1.2.  Responsibilities for HA . . . . . . . . . . . . . . .  10
   4.
   3.  CE HA Hot Standby . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.
     3.1.  Changes to the FEPO model Model . . . . . . . . . . . . . . . .  11
     4.2.
     3.2.  FEPO processing Processing . . . . . . . . . . . . . . . . . . . . .  13
   5.
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   6.
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   7.
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     7.1.
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     7.2.
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Appendix A.  New FEPO version . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . Version . . . . . . . . . . . . . . . . . .  29

2.  20

1.  Introduction
   Figure 1 illustrates a ForCES NE Network Element (NE) controlled by a
   set of redundant CEs Control Elements (CEs) with CE1 being active and CE2
   and CEN CEn being a backup. backups.

                           -----------------------------------------
                           | ForCES Network Element                |
                           |                        +-----------+  |
                           |                        |  CEn      |  |
                           |                        |  (Backup) |  |
     --------------   Fc   | +------------+      +------------+ |  |
     | CE Manager |--------+-|     CE1    |------|    CE2     |-+  |
     --------------        | |  (Active)  |  Fr  |  (Backup)  |    |
           |               | +-------+--+-+      +---+---+----+    |
           | Fl            |         |  |    Fp      /   |         |
           |               |         |  +---------+ /    |         |
           |               |       Fp|            |/     |Fp       |
           |               |         |            |      |         |
           |               |         |      Fp   /+--+   |         |
           |               |         |  +-------+    |   |         |
           |               |         |  |            |   |         |
     --------------    Ff  | --------+--+--      ----+---+----+    |
     | FE Manager |--------+-|     FE1    |  Fi  |     FE2    |    |
     --------------        | |            |------|            |    |
                           | --------------      --------------    |
                           |   |  |  |  |          |  |  |  |      |
                           ----+--+--+--+----------+--+--+--+-------
                               |  |  |  |          |  |  |  |
                               |  |  |  |          |  |  |  |
                                 Fi/f                   Fi/f

          Fp: CE-FE interface
          Fi: FE-FE interface
          Fr: CE-CE interface
          Fc: Interface between the CE Manager manager and a CE
          Ff: Interface between the FE Manager manager and an FE
          Fl: Interface between the CE Manager manager and the FE Manager manager
          Fi/f: FE external interface

                       Figure 1: ForCES Architecture

   The ForCES architecture allows FEs Forwarding Elements (FEs) to be aware
   of multiple CEs but enforces that only one CE be the master
   controller.  This is known in the industry as 1+N redundancy.  The
   master CE controls the FEs via the ForCES protocol operating on the
   Fp interface.  If the master CE becomes faulty, i.e. i.e., crashes or
   loses connectivity, a backup CE takes over and NE operation
   continues.  By definition, the current documented setup is known as cold-standby.
   cold standby.  The set of CEs controlling an FE is static and is
   passed to the FE by the FE Manager (FEM) via the Ff interface and to
   each CE by the CE Manager (CEM) in the Fc interface during the pre-association pre-
   association phase.

   From an FE perspective, the knobs of control operational parameters for a CE set are
   defined
   by as components in the FEPO LFB in [RFC5810], Appendix B.  In
   Section 3.1 2.1 of this
   document document, we discuss further details of these knobs.

2.1.  Document Scope
   parameters.

   It is assumed that the reader is aware of the ForCES architecture to
   make sense of the changes being described in this document.  This
   document provides background information to set the context of the
   discussion in Section 4. 3.

   At the time this document is being written, of writing, the Fr interface is out of scope for the
   ForCES architecture.  However, it is expected that organizations
   implementing a set of CEs will need to have the CEs communicate to
   each other via the Fr interface in order to achieve the
   synchronization necessary for controlling the FEs.

   The problem scope addressed by this document falls into 2 two areas:

   1.  To update the description of [RFC5810] with more clarity on how
       the current cold-standby cold standby approach operates within the NE cluster.

   2.  To describe how to evolve the [RFC5810] cold-standby cold standby setup to a
       hot-standby
       hot standby redundancy setup to improve the failover time and NE
       availability.

2.2.

1.1.  Quantifying Problem Scope

   The

   NE recovery and availability is dependent on several time-
   sensitive time-sensitive
   metrics:

   1.  How fast the CE plane failure is detected by the FE.

   2.  How fast a backup CE becomes operational.

   3.  How fast the FEs associate with the new master CE.

   4.  How fast the FEs recover their state, state and become operational.
       Each FE state is the collective state of all its instantiated
       LFBs.

   The design intent of the current [RFC5810] as well as this document to meet the
   above goals are is driven by desire for simplicity.

   To quantify the above criteria with the current prescribed ForCES CE
   setup in [RFC5810]:

   1.  How fast the FE side detects a CE failure is left undefined.  To
       illustrate an extreme scenario, we could have a human operator
       acting as the monitoring entity to detect faulty CEs.  How fast
       such detection happens could be in the range of seconds to days.
       A more active monitor on the Fp interface could improve this
       detection.  Usually  Usually, the FE will detect a CE failure either by
       the TML if the Fp interface terminates or by the ForCES Protocol protocol
       by utilizing the ForCES heartbeat Heartbeat mechanism.

   2.  How fast the backup CE becomes operational is also currently out
       of scope.  In the current setup, a backup CE need not be
       operational at all (for example, to save power) power), and therefore it
       is feasible for a monitoring entity to boot up a backup CE after
       it detects the failure of the master CE.  In this document Section 4 3 of this
       document, we suggest that at least one backup CE be online so as
       to improve this metric.

   3.  How fast an FE associates with a new master CE is also currently
       undefined.  The cost of an FE connecting and associating adds to
       the recovery overhead.  As mentioned above above, we suggest having at
       least one backup CE online.  In Section 4 3, we propose to zero out remove
       the connection and association cost on failover by having each FE
       associate with all online backup CEs after associating to an
       active/master CE.  Note that if an FE pre-associates with at
       least one backup CE, then the system will be technically
       operating in hot-standby hot standby mode.

   4.  And last: How  Finally, how fast an FE recovers its state depends on how much NE
       state exists.  By the ForCES current definition, the new master
       CE assumes zero state on the FE and starts from scratch to update
       the FE.  So  So, the larger the state, the longer the recovery.

1.

1.2.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The following definitions are taken from [RFC3654], [RFC3746] [RFC3746], and
   [RFC5810].  They are repeated here for convenience as needed, but the
   normative definitions are found in the referenced RFCs:

   o

   Logical Functional Block (LFB) -- (LFB):  A template that represents a
      fine-grained, fine-
      grained, logically separate aspects of FE processing.

   o

   Forwarding Element (FE) - (FE):  A logical entity that implements the ForCES Protocol.
      protocol.  FEs use the underlying hardware to provide per-
      packet per-packet
      processing and handling as directed by a CE via the ForCES
      Protocol.

   o
      protocol.

   Control Element (CE) - (CE):  A logical entity that implements the ForCES
      Protocol
      protocol and uses it to instruct one or more FEs on how to process
      packets.  CEs handle functionality such as the execution of
      control and signaling protocols.

   o

   ForCES Network Element (NE) - (NE):  An entity composed of one or more CEs
      and one or more FEs.  An NE usually hides its internal
      organization from external entities and represents a single point
      of management to entities outside the NE.

   o

   FE Manager (FEM) - (FEM):  A logical entity that operates in the pre-
      association phase and is responsible for determining to which
      CE(s) an FE should communicate.  This process is called CE
      discovery and may involve the FE manager learning the capabilities
      of available CEs.

   o

   CE Manager - (CEM):  A logical entity that operates in the pre-association pre-
      association phase and is responsible for determining to which
      FE(s) a CE should communicate.  This process is called FE
      discovery and may involve the CE manager learning the capabilities
      of available FEs.

   o

   ForCES Protocol -- Protocol:  The protocol used for communication
      communication between CEs and
      FEs.  This protocol does not apply to CE-to-CE communication, FE-to-FE FE-
      to-FE communication, or to communication between FE and CE
      managers.  The ForCES protocol is a master-slave protocol in which
      FEs are slaves and CEs are masters.  This protocol includes both
      the management of the communication channel (e.g., connection establishment,
      establishment and heartbeats) and the control messages themselves.

   o

   ForCES Protocol Layer (ForCES PL) -- PL):  A layer in the ForCES protocol
      architecture that defines the ForCES protocol messages, the
      protocol state transfer scheme, and the ForCES protocol
      architecture itself (including requirements of ForCES TML Transport
      Mapping Layer (TML) as shown below).  Specifications of ForCES PL
      are defined in [RFC5810]

   o [RFC5810].

   ForCES Protocol Transport Mapping Layer (ForCES TML) -- TML):  A layer in the
      ForCES protocol architecture that specifically addresses the
      protocol message transportation issues, such as how the protocol
      messages are mapped to different transport media (like SCTP, Stream
      Control Transmission Protocol (SCTP), IP, TCP, UDP, ATM, Ethernet, etc),
      etc.), and how to achieve and implement reliability, security,
      etc.

3.  RFC5810

2.  RFC 5810 CE HA Framework

   To achieve CE High Availability (HA), FEs and CEs MUST inter-operate interoperate
   per [RFC5810] the definition in [RFC5810], which is repeated for contextual
   reasons in Section 3.1. 2.1.  It should be noted that in this default
   setup, which MUST be implemented by CEs and FEs requiring HA, the Fr
   plane is out of scope (and if available available, is proprietary to an
   implementation).

3.1.

2.1.  RFC 5810 CE HA Support

   As mentioned earlier, although there can be multiple redundant CEs,
   only one CE actively controls FEs in a ForCES NE.  In practice practice, there
   may be only one backup CE.  At any moment in time, only one master CE
   can control an FE.  In addition, the FE connects and associates to
   only the master CE.  The FE and the CE are aware of the primary and
   one or more secondary CEs.  This information (primary, (primary and secondary
   CEs) is configured on the FE and the CE during pre-association by the
   FEM and the CEM CEM, respectively.

   This section includes a new normative description that updates
   [RFC5810] for the Cold-Standby Cold Standby High Availability mechanism.

   Figure 2 below illustrates the Forces ForCES message sequences that the FE
   uses to recover the connection in current the currently defined cold-standby cold standby
   scheme.

         FE                       CE Primary         CE Secondary
         |                           |                     |
         | Association Establishment |                     |
         |   Capabilities Exchange   |                     |
       1 |<------------------------->|                     |
         |                           |                     |
         |       State Update        |                     |
       2 |<------------------------->|                     |
         |                           |                     |
         |                           |                     |
         |                        FAILURE                  |
         |                                                 |
         | Association Estbalishment,Capabilities Exchange | Establishment, Capabilities Exchange|
       3 |<----------------------------------------------->|
         |                                                 |
         |         Event Report (primary CE down)          |
       4 |------------------------------------------------>|
         |                                                 |
         |                  State Update                   |
       5 |<----------------------------------------------->|

                  Figure 2: CE Failover for Cold Standby

3.1.1.

2.1.1.  Cold Standby Interaction with the ForCES Protocol

   HA parameterization in an FE is driven by configuring the FE Protocol
   Object (FEPO) LFB.

   The FEPO CEID Control Element ID (CEID) component identifies the current
   master CE CE, and the component table BackupCEs identifies the
   configured backup CEs.  The FEPO FE Heartbeat Interval, Interval (FEHI), CE
   Heartbeat Dead Interval, Interval (CEHDI), and CE Heartbeat policy help in
   detecting connectivity problems between an FE and CE.  The CE Failover
   failover policy defines how the FE should react on a detected
   failure.  The FEObject FEState component [RFC5812] defines the
   operational forwarding status and control.  The CE can turn off the
   FE's forwarding operations by setting the FEState to AdminDisable and
   can turn it on by setting it to OperEnable.  Note: [RFC5812]
   section Section 5.1 of
   [RFC5812] has been updated by an errata which erratum ([Err3487]) that describes
   the FEState as read-only when it should be read-write.

   Figure 3 illustrates the defined state machine that facilitates the
   recovery of the connection state.

   The FE connects to the CE specified on the FEPO CEID component.  If
   it fails to connect to the defined CE, it moves it to the bottom of
   table BackupCEs and sets its CEID component to be the first CE
   retrieved from table BackupCEs.  The FE then attempts to associate
   with the CE designated as the new primary CE.  The FE continues
   through this procedure until it successfully connects to one of the
   CEs or until the CE Failover Timeout Interval (CEFTI) expires.

                             FE tries to associate
                                   +-->-----+
                                   |        |
      (CE changes master ||        |        |
      CE issues Teardown ||    +---+--------v----+
        Lost association) &&   | Pre-Association Pre-association |
       CE failover policy = 0  | (Association    |
           +------------>-->-->|   in            +<----+
           |                   | progress)       |     |
           |                   |                 |     |
           |                   +--------+--------+     |
           |  CE Association        |                  | CEFTI
           |       Response         V                  | timer
           |     +------------------+                  | expires
           |     |FE issue issues CEPrimaryDown              ^
           |     V                                     |
         +-+-----------+                        +------+-----+
         |             |  (CE changes master || | Not        |
         |             |  CE issues Teardown || | Associated |
         |             |  Lost association) &&  |            +->---+
         | Associated  | CE Failover Policy failover policy = 1 |(May        | FE  |
         |             |                        | Continue   | try v
         |             |-------->------->------>| Forwarding)| assn|
         |             |   Start CEFTI timer    |            |-<---+
         |             |                        |            |
         +-------------+                        +-------+-----+                        +-------+----+
              ^                                         |
              |            Successful                   V
              |            Association                  |
              |            Setup                        |
              |            (Cancel CEFTI Timer) timer)         |
              +_________________________________________+
                       FE issue issues CEPrimaryDown event

                 Figure 3: FE State Machine considering Considering HA

   There are several events that trigger mastership changes: changes.  The master
   CE may issue a mastership change (by changing the CEID component), or
   teardown it
   may tear down an existing association; and last, association, or connectivity may be lost
   between the CE and FE.

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

   If the FE's FEPO CE Failover Policy failover policy is configured to mode 0 (the
   default), it will immediately transition to the pre-association
   phase.  This means that if association is later re-established with a
   CE, all FE state states will need to be re-created.

   If the FE's FEPO CE Failover Policy failover policy is configured to mode 1, it
   indicates that the FE will run in HA restart recovery.  In such a
   case, the FE transitions to the Not Associated not associated state and the CEFTI
   timer [RFC5810] is started.  The FE may continue to forward packets
   during this state state, depending upon the value of the CEFailoverPolicy
   component of the FEPO LFB.  The FE recycles through any configured
   backup CEs in a round-robin fashion.  It first adds its primary CE to
   the bottom of table BackupCEs and sets its CEID component to be the
   first secondary retrieved from table BackupCEs.  The FE 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 and the FE will
   operationally bring down its forwarding path (and set the [RFC5812]
   FEObject FEState component to OperDisable).

   If the FE, while in the not associated state, manages to reconnect to
   a new primary CE before the CEFTI expires expires, it transitions to the
   Associated
   associated state.  Once re-associated, the CE may try to synchronize
   any state that the FE may have lost during disconnection.  How the CE
   re-synchronizes such a state is out of scope for the current ForCES
   architecture but would typically constitute the issuing of new
   configs Config
   messages and queries.

   An explicit message (a Config message setting Primary the primary CE
   component in the ForCES Protocol object) Object) from the primary CE, CE can also
   be used to change the Primary primary CE for an FE during normal protocol
   operation.  In this case, the FE transitions to the Not Associated State not associated
   state and attempts to Associate associate with the new CE.

3.1.2.

2.1.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 example, the
   transport level (such as IP addresses, MAC addresses etc) Media Access Control (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 Control Element IDs (CE IDs) used to identify primary and
   secondary CEs, protocol messages used to report CE failure (Event
   Report), (event
   report), Heartbeat messages used to detect association failure,
   messages to change the primary CE (Config), and other HA related HA-related
   operations described in Section 3.1, 2.1, are the PL's responsibility.

   To put the two together, if a path to a primary CE is down, the TML
   would help recover from a failure by switching over to a backup path,
   if one is available.  If the CE is totally unreachable unreachable, then the PL
   would be informed and it would take the appropriate actions described
   before.

4.

3.  CE HA Hot Standby

   In this section section, we describe small extensions to the existing scheme
   to enable hot standby HA.  To achieve hot standby HA, we target aim to
   improve the specific goals defined in Section 2.2, 1.1, namely:

   o  How fast a backup CE becomes operational.

   o  How fast the FEs associate with the new master CE.

   As described in Section 3.1, 2.1, in the pre-association phase phase, the FEM
   configures the FE to make it aware of all the CEs in the NE.  The FEM
   MUST configure the FE to make it aware of which CE is the master and
   MAY specify any backup CE(s).

4.1.

3.1.  Changes to the FEPO model Model

   In order for the above to be achievable achievable, there is a need to make a
   few changes in the FEPO model.  Appendix A contains the xml
   definition of the new version 1.1 of the FEPO LFB.

   Changes from the version 1 of the FEPO are:

   1.  Added four new datatypes:

       1.  CEStatusType -- an unsigned char to specify the status of a
           connection with a CE.  Special values are:

           +  0 (Disconnected) represents that no connection attempt has
              been made with the CE yet

           +  1 (Connected) represents that the FE connection with the
              CE at the TML has completed successfully

           +  2 (Associated) represents that the FE has successfully
              associated with the CE

           +  3 (IsMaster) represents that the FE has associated with
              the CE and is the master of the FE

           +  4 (LostConnection) represents that the FE was associated
              with the CE at one point but lost the connection

           +  5 (Unreachable) represents that the FE deems this CE
              unreachable.
              unreachable, i.e., the FE has tried over a period to
              connect to it but has failed. failed

       2.  HAModeValues -- an unsigned char to specify a selected HA
           mode.  Special values are:

           +  0 (No HA Mode) represents that the FE is not running in HA
              mode

           +  1 (HA Mode - Cold Standby) represents that the FE is in HA
              mode cold Standby standby

           +  2 (HA Mode - Hot Standby) represents that the FE is in HA
              mode hot Standby standby

       3.  Statistics,  Statistics -- a complex structure, structure representing the
           communication statistics between the FE and CE.  The
           components are:

           +  RecvPackets  RecvPackets, representing the packet count received from
              the CE

           +  RecvBytes  RecvBytes, representing the byte count received from the
              CE

           +  RecvErrPackets  RecvErrPackets, representing the erroneous packets
              received from the CE.  This component logs badly formatted
              packets as well as good packets sent to the FE by the CE
              to set components whilst that CE is not the master.
              Erroneous packets are dropped(i.e. dropped (i.e., not responded to).

           +  RecvErrBytes  RecvErrBytes, representing the RecvErrPackets byte count
              received from the CE

           +  TxmitPackets  TxmitPackets, representing the packet count transmitted to
              the CE

           +  TxmitErrPackets  TxmitErrPackets, representing the error packet count
              transmitted to the CE.  Typically  Typically, these would be failures
              due to communication.

           +  TxmitBytes  TxmitBytes, representing the byte count transmitted to the
              CE

           +  TxmitErrBytes  TxmitErrBytes, representing the byte count of errors from
              transmit to the CE

       4.  AllCEType,  AllCEType -- a complex structure constituting the CE IDs,
           Statistics
           statistics, and CEStatusType to reflect connection
           information for one CE.  Used in the AllCEs AllCE's component array.

   2.  Appended two new components:

       1.  Read-only AllCEs to hold the status for all CEs.  AllCEs is
           an
           Array array of the AllCEType.

       2.  Read-write HAMode of type HAModeValues to carry the HA mode
           used by the FE.

   3.  Added one additional Event, event, PrimaryCEChanged, reporting the new
       master CE ID when there is a mastership change.

   Since no component from the FEPO v1 has been changed changed, FEPO v1.1 retains
   backwards compatibility with CEs that know only version 1.0.  These CEs however
   CEs, however, cannot make use of the HA options that the new FEPO
   provides.

4.2.

3.2.  FEPO processing Processing

   The FE's FEPO LFB version 1.1 AllCEs table contains all the CE IDs
   that
   with which the FE may connect and associate with. associate.  The ordering of the CE
   IDs in this table defines the priority order in which an FE will
   connect to the CEs.  This table is provisioned initially from the
   configuration plane (FEM).  In the pre-association phase, the first
   CE (lowest table index) in the AllCEs table MUST be the first CE that with
   which the FE will attempt to connect and associate with. associate.  If the FE fails
   to connect and associate with the first listed CE, it will attempt to
   connect to the second CE and so forth, and it cycles back to the
   beginning of the list until there is a successful association.  The
   FE MUST associate with at least one CE.  Upon a successful
   association, a component of the FEPO LFB, specifically the CEID
   component, identifies the current associated master CE.

   While it would be much simpler to have the FE not respond to any
   messages from a CE other than the master, in practice it has been
   found to be useful to respond to queries and heartbeats from backup
   CEs.  For this reason, we allow backup CEs to issues issue queries to the
   FE.  Configuration messages (SET/DEL) from backup CEs MUST be dropped
   by the FE and logged as received errors.

   Asynchronous events that the master CE has subscribed to, as well as
   heartbeats
   heartbeats, are sent to all associated-to associated CEs.  Packet redirects
   continue to be sent only to the master CE.  The Heartbeat Interval,
   the CE Heartbeat Policy (CEHB) policy, and the FE Heartbeat Policy (FEHB) policy
   are global for all CEs(and CEs (and changed only by the master CE).

   Figure 4 illustrates the state machine that facilitates connection
   recovery with HA enabled.

                           FE tries to associate
                                +-->-----+
                                |        |
   (CE changes master ||        |        |
   CE issues Teardown ||    +---+--------v----+
     Lost association) &&   | Pre-Association Pre-association |
    CE failover policy = 0  | (Association    |
        +------------>-->-->|   in            +<----+
        |                   | progress)       |     |
        |                   |                 |     |
        |                   +--------+--------+     |
        |  CE Association        |                  | CEFTI
        |       Response         V                  | timer
        |     +------------------+                  | expires
        |     |FE issue issues CEPrimaryDown              ^
        |     |FE issue issues PrimaryCEChanged           ^
        |     V                                     |
      +-+-----------+                        +------+-----+
      |             |  (CE changes master || | Not        |
      |             |  CE issues Teardown || | Associated |
      |             |  Lost association) &&  |            +->----------+
      | Associated  | CE Failover Policy failover policy = 1 |(May        | find first |
      |             |                        | Continue   | associated v
      |             |-------->------->------>| Forwarding)| CE or retry|
      |             |   Start CEFTI timer    |            | associating|
      |             |                        |            |-<----------+
      |             |                        |            |
      +----+--------+                        +-------+----+
           |                                         |
           ^                                   Found | associated CE
           |                                or newly | associated CE
           |                                         V
           |            (Cancel CEFTI Timer) timer)         |
           +_________________________________________+
                    FE issue issues CEPrimaryDown event
                    FE issue issues PrimaryCEChanged event

                 Figure 4: FE State Machine considering Considering HA

   Once the FE has associated with a master CE CE, it moves to the post-
   association phase (Associated (associated state).  It is assumed that the master
   CE will communicate with other CEs within the NE for the purpose of
   synchronization via the CE-CE interface.  The CE-CE interface is out
   of scope for this document.  An election result amongst CEs may
   result in the desire to change the mastership to a different
   associated CE; at which point point, the current assumed master CE will
   instruct the FE to use a different master CE.

         FE                         CE#1         CE#2 ... CE#N
         |                           |            |        |
         | Association Establishment |            |        |
         |   Capabilities Exchange   |            |        |
       1 |<------------------------->|            |        |
         |                           |            |        |
         |      State Update         |            |        |
       2 |<------------------------->|            |        |
         |                           |            |        |
         |      Association Establishment         |        |
         |        Capabilities Exchange           |        |
       3I|<-------------------------------------->|        |
        ...                         ...          ...      ...
         | Association Estbalishment,Capabilities
         |Association Establishment, Capabilities Exchange |
       3N|<----------------------------------------------->|
         |                           |            |        |
       4 |<------------------------->|            |        |
         .                           .            .        .
       4x|<------------------------->|            |        |
         |                        FAILURE         |        |
         |                           |            |        |
         |    Event Report (LastCEID changed)     |        |
       5 |--------------------------------------->|------->|
         |    Event Report (CE#2 is new master)   |        |
       6 |--------------------------------------->|------->|
         |                                        |        |
       7 |<-------------------------------------->|        |
         .                           .            .        .
       7x|<-------------------------------------->|        |
         .                           .            .        .

                   Figure 5: CE Failover for Hot Standby

   While in the post-association phase, if the CE Failover Policy failover policy is set
   to 1 and the HAMode is set to 2 (HotStandby) (hot standby), then the FE, after
   successfully associating with the master CE, MUST attempt to connect
   and associate with all the CEs that of which it is aware of. aware.  Figure 5 5, steps
   #1 and #2 illustrates the FE associating with CE#1 as the master master, and
   then proceeding to steps #3I to #3N #3N, it shows the association with
   backup CEs CE#2 to CE#N.  If the FE fails to connect or associate
   with some CEs, the FE MAY flag them as unreachable to avoid
   continuous attempts to connect.  The FE MAY retry try to reassociate re-associate with
   unreachable CEs when possible.

   When the master CE CE, for any reason reason, is considered to be down, then
   the FE MUST try to find the first associated CE from the list of all
   CEs in a round-robin fashion.

   If the FE is unable to find an associated FE in its list of CEs, then
   it MUST attempt to connect and associate with the first from the list
   of all CEs and continue in a round-robin fashion until it connects
   and associates with a CE or the CEFTI timer expires.

   Once the FE selects an associated CE to use as the new master, the FE
   issues a PrimaryCEDown Event Notification to all associated CEs to
   notify them that the last primary CE went down (and what its identity
   was); a second event PrimaryCEChanged event, PrimaryCEChanged, identifying the new master CE
   is sent as well to identify which CE the reporting FE considers to be
   the new master.

   In most HA architectures architectures, there exists the possibility of split-brain. split
   brain.  However, since in our setup setup, since the FE will never accept any
   configuration messages from any other than the master CE, we consider
   the FE as to be fenced against data corruption from the other CEs that
   consider themselves as the master.  The split-brain issue becomes
   mostly a CE-CE communication problem problem, which is considered to be out
   of scope.

   By virtue of having multiple CE connections, the FE switchover to a
   new master CE will be relatively much faster.  The overall effect is
   improving the NE recovery time in case of communication failure or
   faults of the master CE.  This satisfies the requirement we set to
   achieve.

5.
   fulfill.

4.  IANA Considerations

   Following the policies outlined in "Guidelines for Writing an IANA
   Considerations Section in RFCs" [RFC5226], the Logical "Logical Functional
   Block (LFB) Class Names and Class Identifiers namespaces is Identifiers" namespace has been
   updated.

   A new column, LFB version, is has been added to the table after the LFB
   Class Name.  The table now reads as follows:

   +----------------+------------+-----------+-------------+-----------+
   |   LFB Class    | LFB Class  |    LFB    | Description | Reference |
   |   Identifier   |    Name    |  Version  |             |           |
   +----------------+------------+-----------+-------------+-----------+
   +----------------+------------+-----------+-------------+-----------+

     Logical Functional Block (LFB) Class Names and Class Identifiers

   The same rules applies as defined in [RFC5812] apply, with the addition that entries
   must provide the LFB version as a string.

   Upon publication of this document, all current entries are assigned a
   value of 1.0.

   New versions of already defined LFB, LFBs MUST NOT remove the previous
   version entries.

   It would make sense to have LFB versions to appear in sequence in the
   registry.  The table SHOULD be sorted, and the shorting sorting should be done
   by Class ID first and then by version.

   This document introduces the FE Protocol Object version 1.1 as
   follows:

   +------------+-----------+---------+--------------------+-----------+

   +------------+----------+---------+---------------------+-----------+
   | LFB Class  |   LFB Class    |   LFB   |     Description     | Reference |
   | Identifier |    Name  Class   | Version |                     |           |
   +------------+-----------+---------+--------------------+-----------+
   |            |   Name   |         |                     |           |
   +------------+----------+---------+---------------------+-----------+
   |     2      |    FE    |   1.1   |  Defines parameters |    This [RFC7121] |
   |            | Protocol |         |    for the ForCES   |  document           |
   |            |  Object  |         |  protocol operation |           |
   +------------+-----------+---------+--------------------+-----------+
   +------------+----------+---------+---------------------+-----------+

     Logical Functional Block (LFB) Class Names and Class Identifiers

6.

5.  Security Considerations

   Security consideration considerations, as defined in section Section 9 of [RFC5810] applies [RFC5810], apply
   to securing each CE-FE communication.  Multiple CEs associated with
   the same FE still require the same procedure to be followed on a per-
   association basis.

   It should be noted that since the FE is initiating the association
   with a CE, a CE cannot initiate association with the FE and such
   messages will be dropped.  Thus  Thus, the FE is secured from rogue CEs
   that are attempting to associate with it.

   CE implementers should have in mind that once associated associated, the FE
   cannot distinguish whether the CE has been compromised or has been
   malfunctioning while not losing connectivity.  Securing the CE is out
   of scope of this document.

   While the CE-CE plane is outside the current scope of ForCES, we
   recognize that it may be subjected to attacks which that may affect the CE-FE CE-
   FE communication.

   The following considerations should be made:

   1.  CEs should use secure  Secure communication channels should be used between CEs for
       coordination and keeping of state to at least to avoid connection of
       malicious CEs.

   2.  The master CE should take into account DoS and DDoS Distributed
       Denial-of-Service (DDoS) attacks from malicious or malfunctioning
       CEs.

   3.  CEs should take into account the split-brain issue.  There are
       currently two fail-safes in the FE, firstly FE: Firstly, the FE has the CEID
       component that denotes which CE is the master and secondly master.  Secondly, the FE
       does not allow BackupCEs to configure the FE.  However  However, backup
       CEs that consider that the master CE has dropped and themselves should, as
       master should
       masters themselves, first do a sanity check and query the FE CEID
       component.

7.

6.  References

7.1.

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5810]  Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
              W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
              Control Element Separation (ForCES) Protocol
              Specification", RFC 5810, March 2010.

   [RFC5812]  Halpern, J. and J. Hadi Salim, "Forwarding and Control
              Element Separation (ForCES) Forwarding Element Model", RFC
              5812, March 2010.

7.2.

6.2.  Informative References

   [Err3487]  RFC Errata, "Errata ID 3487", RFC 3487,
              <http://www.rfc-editor.org>.

   [RFC3654]  Khosravi, H. and T. Anderson, "Requirements for Separation
              of IP Control and Forwarding", RFC 3654, November 2003.

   [RFC3746]  Yang, L., Dantu, R., Anderson, T., and R. Gopal,
              "Forwarding and Control Element Separation (ForCES)
              Framework", RFC 3746, April 2004.

Appendix A.  New FEPO version Version

   The xml has been validated against the schema defined in [RFC5812].

<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="lfb-schema.xsd" provides="FEPO">
   <!-- XXX -->
   <dataTypeDefs>
      <dataTypeDef>
         <name>CEHBPolicyValues</name>
         <synopsis>
            The possible values of the CE heartbeat Heartbeat policy
         </synopsis>
         <atomic>
            <baseType>uchar</baseType>
            <specialValues>
               <specialValue value="0">
                  <name>CEHBPolicy0</name>
                  <synopsis>
              The CE will send heartbeats to the FE
              every CEHDI timeout if no other messages
              have been sent since.
                  </synopsis>
               </specialValue>
               <specialValue value="1">
                  <name>CEHBPolicy1</name>
                  <synopsis>
              The CE will not send heartbeats to the FE
                  </synopsis>
               </specialValue>
            </specialValues>
         </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>FEHBPolicyValues</name>
         <synopsis>
            The possible values of the FE heartbeat Heartbeat policy
         </synopsis>
         <atomic>
            <baseType>uchar</baseType>
            <specialValues>
               <specialValue value="0">
                  <name>FEHBPolicy0</name>
                  <synopsis>
        The FE will not generate any heartbeats to the CE
                  </synopsis>
               </specialValue>
               <specialValue value="1">
                  <name>FEHBPolicy1</name>
                  <synopsis>
        The FE generates heartbeats to the CE every FEHI
        if no other messages have been sent to the CE.
                  </synopsis>
               </specialValue>
            </specialValues>
         </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>FERestartPolicyValues</name>
         <synopsis>
            The possible values of the FE restart policy
         </synopsis>
         <atomic>
            <baseType>uchar</baseType>
            <specialValues>
               <specialValue value="0">
                  <name>FERestartPolicy0</name>
                  <synopsis>
                     The FE restarts its state from scratch
                  </synopsis>
               </specialValue>
            </specialValues>
         </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>HAModeValues</name>
         <synopsis>
            The possible values of HA modes
         </synopsis>
         <atomic>
            <baseType>uchar</baseType>
            <specialValues>
               <specialValue value="0">
                  <name>NoHA</name>
                  <synopsis>
                     The FE is not running in HA mode
                  </synopsis>
               </specialValue>
               <specialValue value="1">
                  <name>ColdStandby</name>
                  <synopsis>
                     The FE is running in HA mode cold Standby standby
                  </synopsis>
               </specialValue>
               <specialValue value="2">
                  <name>HotStandby</name>
                  <synopsis>
                     The FE is running in HA mode hot Standby standby
                  </synopsis>
               </specialValue>
            </specialValues>
         </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>CEFailoverPolicyValues</name>
         <synopsis>
            The possible values of the CE failover policy
         </synopsis>
         <atomic>
            <baseType>uchar</baseType>
            <specialValues>
               <specialValue value="0">
                  <name>CEFailoverPolicy0</name>
                  <synopsis>
        The FE should stop functioning immediate immediately and
        transition to the FE OperDisable state
                  </synopsis>
               </specialValue>
               <specialValue value="1">
                  <name>CEFailoverPolicy1</name>
                  <synopsis>
        The FE should continue forwarding even without an
        associated CE for CEFTI. The FE goes to FE
        OperDisable when the CEFTI expires and there is no
        association. Requires graceful restart support.
                  </synopsis>
               </specialValue>
            </specialValues>
         </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>FEHACapab</name>
         <synopsis>
            The supported HA features
         </synopsis>
         <atomic>
            <baseType>uchar</baseType>
            <specialValues>
               <specialValue value="0">
                  <name>GracefullRestart</name>
                  <synopsis>
                     The FE supports Graceful Restart graceful restart
                  </synopsis>
               </specialValue>
               <specialValue value="1">
                  <name>HA</name>
                  <synopsis>
                     The FE supports HA
                  </synopsis>
               </specialValue>
            </specialValues>
         </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>CEStatusType</name>
         <synopsis>Status values. Status for each CE</synopsis>
         <atomic>
            <baseType>uchar</baseType>
            <specialValues>
               <specialValue value="0">
                  <name>Disconnected</name>
                  <synopsis>No connection attempt with the CE yet
                  </synopsis>
               </specialValue>
               <specialValue value="1">
                  <name>Connected</name>
                  <synopsis>The FE connection with the CE at the TML
                     has been completed
                  </synopsis>
               </specialValue>
               <specialValue value="2">
                  <name>Associated</name>
                  <synopsis>The FE has associated with the CE
                  </synopsis>
               </specialValue>
               <specialValue value="3">
                  <name>IsMaster</name>
                  <synopsis>The CE is the master (and associated)
                  </synopsis>
               </specialValue>
               <specialValue value="4">
                  <name>LostConnection</name>
                  <synopsis>The FE was associated with the CE but
                     lost the connection
                  </synopsis>
               </specialValue>
               <specialValue value="5">
                  <name>Unreachable</name>
                  <synopsis>The CE is deemed as unreachable by the FE
                  </synopsis>
               </specialValue>
            </specialValues>
         </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>StatisticsType</name>
         <synopsis>Statistics Definition</synopsis>
         <struct>
            <component componentID="1">
               <name>RecvPackets</name>
               <synopsis>Packets Received</synopsis> received</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>RecvErrPackets</name>
               <synopsis>Packets Received received from the CE with errors
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="3">
               <name>RecvBytes</name>
               <synopsis>Bytes Received received from the CE</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="4">
               <name>RecvErrBytes</name>
               <synopsis>Bytes Received received from the CE in Error</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="5">
               <name>TxmitPackets</name>
               <synopsis>Packets Transmitted transmitted to the CE</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="6">
               <name>TxmitErrPackets</name>
               <synopsis>
                  Packets Transmitted transmitted to the CE that incurred
                  errors
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="7">
               <name>TxmitBytes</name>
               <synopsis>Bytes Transmitted transmitted to the CE</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="8">
               <name>TxmitErrBytes</name>
               <synopsis>Bytes Transmitted transmitted to the CE incurring that incurred errors
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>AllCEType</name>
         <synopsis>Table Type type for the AllCE component</synopsis>
         <struct>
            <component componentID="1">
               <name>CEID</name>
               <synopsis>ID of the CE</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>Statistics</name>
               <synopsis>Statistics per the CE</synopsis>
               <typeRef>StatisticsType</typeRef>
            </component>
            <component componentID="3">
               <name>CEStatus</name>
               <synopsis>Status of the CE</synopsis>
               <typeRef>CEStatusType</typeRef>
            </component>
         </struct>
      </dataTypeDef>
   </dataTypeDefs>
   <LFBClassDefs>
      <LFBClassDef LFBClassID="2">
         <name>FEPO</name>
         <synopsis>
            The FE Protocol Object, with new CEHA
         </synopsis>
         <version>1.1</version>
         <components>
            <component componentID="1" access="read-only">
               <name>CurrentRunningVersion</name>
               <synopsis>Currently running the ForCES version</synopsis>
               <typeRef>uchar</typeRef>
            </component>
            <component componentID="2" access="read-only">
               <name>FEID</name>
               <synopsis>Unicast FEID</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3" access="read-write">
               <name>MulticastFEIDs</name>
               <synopsis>
                     the
                  The table of all multicast IDs
               </synopsis>
               <array type="variable-size">
                  <typeRef>uint32</typeRef>
               </array>
            </component>
            <component componentID="4" access="read-write">
               <name>CEHBPolicy</name>
               <synopsis>
                  The CE Heartbeat Policy policy
               </synopsis>
               <typeRef>CEHBPolicyValues</typeRef>
            </component>
            <component componentID="5" access="read-write">
               <name>CEHDI</name>
               <synopsis>
                  The CE Heartbeat Dead Interval in millisecs milliseconds
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="6" access="read-write">
               <name>FEHBPolicy</name>
               <synopsis>
                  The FE Heartbeat Policy policy
               </synopsis>
               <typeRef>FEHBPolicyValues</typeRef>
            </component>
            <component componentID="7" access="read-write">
               <name>FEHI</name>
               <synopsis>
                  The FE Heartbeat Interval in millisecs milliseconds
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="8" access="read-write">
               <name>CEID</name>
               <synopsis>
                  The Primary primary CE this FE is associated with
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="9" access="read-write">
               <name>BackupCEs</name>
               <synopsis>
                  The table of all backup CEs other than the
                  primary
               </synopsis>
               <array type="variable-size">
                  <typeRef>uint32</typeRef>
               </array>
            </component>
            <component componentID="10" access="read-write">
               <name>CEFailoverPolicy</name>
               <synopsis>
                  The CE Failover Policy failover policy
               </synopsis>
               <typeRef>CEFailoverPolicyValues</typeRef>
            </component>
            <component componentID="11" access="read-write">
               <name>CEFTI</name>
               <synopsis>
                  The CE Failover Timeout Interval in millisecs milliseconds
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="12" access="read-write">
               <name>FERestartPolicy</name>
               <synopsis>
                  The FE Restart Policy restart policy
               </synopsis>
               <typeRef>FERestartPolicyValues</typeRef>
            </component>
            <component componentID="13" access="read-write">
               <name>LastCEID</name>
               <synopsis>
                  The Primary primary CE this FE was last associated
                  with
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="14" access="read-write">
               <name>HAMode</name>
               <synopsis>
                  The HA mode used
               </synopsis>
               <typeRef>HAModeValues</typeRef>
            </component>
            <component componentID="15" access="read-only">
               <name>AllCEs</name>
               <synopsis>The table of all CEs</synopsis>
               <array type="variable-size">
                  <typeRef>AllCEType</typeRef>
               </array>
            </component>
         </components>
         <capabilities>
            <capability componentID="30">
               <name>SupportableVersions</name>
               <synopsis>
                     the
                  The table of ForCES versions that FE supports
               </synopsis>
               <array type="variable-size">
                  <typeRef>uchar</typeRef>
               </array>
            </capability>
            <capability componentID="31">
               <name>HACapabilities</name>
               <synopsis>
                     the
                  The table of HA capabilities the FE supports
               </synopsis>
               <array type="variable-size">
                  <typeRef>FEHACapab</typeRef>
               </array>
            </capability>
         </capabilities>
         <events baseID="61">
            <event eventID="1">
               <name>PrimaryCEDown</name>
               <synopsis>
                  The primary CE has changed
               </synopsis>
               <eventTarget>
                  <eventField>LastCEID</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>LastCEID</eventField>
                  </eventReport>
               </eventReports>
            </event>
            <event eventID="2">
               <name>PrimaryCEChanged</name>
               <synopsis>A New new primary CE has been selected
               </synopsis>
               <eventTarget>
                  <eventField>CEID</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>CEID</eventField>
                  </eventReport>
               </eventReports>
            </event>
         </events>
      </LFBClassDef>
   </LFBClassDefs>
</LFBLibrary>

Authors' Addresses

   Kentaro Ogawa
   NTT Corporation
   3-9-11 Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Email:

   EMail: k.ogawa@ntt.com

   Weiming Wang
   Zhejiang Gongshang University
   149 Jiaogong Road
   Hangzhou  310035
   P.R.China

   Phone: +86-571-88057712
   Email:
   EMail: wmwang@mail.zjgsu.edu.cn

   Evangelos Haleplidis
   University of Patras
   Panepistimioupoli Patron
   Department of Electrical and Computer Engineering
   Patras  26504  26500
   Greece

   Email:

   EMail: ehalep@ece.upatras.gr

   Jamal Hadi Salim
   Mojatatu Networks
   Suite 400, 303 Moodie Dr.
   Ottawa, Ontario  K2H 9R4
   Canada

   Email:

   EMail: hadi@mojatatu.com