draft-ietf-forces-ceha-08.txt   draft-ietf-forces-ceha-09.txt 
Network Working Group K. Ogawa Network Working Group K. Ogawa
Internet-Draft NTT Corporation Internet-Draft NTT Corporation
Updates: 5810 (if approved) W. M. Wang Updates: 5810 (if approved) W. M. Wang
Intended status: Standards Track Zhejiang Gongshang University Intended status: Standards Track Zhejiang Gongshang University
Expires: April 17, 2014 E. Haleplidis Expires: May 24, 2014 E. Haleplidis
University of Patras University of Patras
J. Hadi Salim J. Hadi Salim
Mojatatu Networks Mojatatu Networks
October 14, 2013 November 20, 2013
ForCES Intra-NE High Availability ForCES Intra-NE High Availability
draft-ietf-forces-ceha-08 draft-ietf-forces-ceha-09
Abstract Abstract
This document discusses Control Element High Availability within a This document discusses Control Element High Availability within a
ForCES Network Element. Additionally this document updates [RFC5810] ForCES Network Element. Additionally this document updates [RFC5810]
by providing new normative text for the Cold-Standby High by providing new normative text for the Cold-Standby High
availability mechanism. availability mechanism.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2014. This Internet-Draft will expire on May 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 5 2.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 5
2.2. Quantifying Problem Scope . . . . . . . . . . . . . . . . 5 2.2. Quantifying Problem Scope . . . . . . . . . . . . . . . . 5
3. RFC5810 CE HA Framework . . . . . . . . . . . . . . . . . . . 6 3. RFC5810 CE HA Framework . . . . . . . . . . . . . . . . . . . 6
3.1. RFC 5810 CE HA Support . . . . . . . . . . . . . . . . . 6 3.1. RFC 5810 CE HA Support . . . . . . . . . . . . . . . . . 6
3.1.1. Cold Standby Interaction with ForCES Protocol . . . . 7 3.1.1. Cold Standby Interaction with ForCES Protocol . . . . 7
3.1.2. Responsibilities for HA . . . . . . . . . . . . . . . 9 3.1.2. Responsibilities for HA . . . . . . . . . . . . . . . 10
4. CE HA Hot Standby . . . . . . . . . . . . . . . . . . . . . . 10 4. CE HA Hot Standby . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Changes to the FEPO model . . . . . . . . . . . . . . . . 10 4.1. Changes to the FEPO model . . . . . . . . . . . . . . . . 11
4.2. FEPO processing . . . . . . . . . . . . . . . . . . . . . 12 4.2. FEPO processing . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. New FEPO version . . . . . . . . . . . . . . . . . . 17 Appendix A. New FEPO version . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Definitions 1. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following definitions are taken from [RFC3654], [RFC3746] and The following definitions are taken from [RFC3654], [RFC3746] and
[RFC5810]. They are repeated here for convenience as needed, but the [RFC5810]. They are repeated here for convenience as needed, but the
normative definitions are found in the referenced RFCs: normative definitions are found in the referenced RFCs:
o Logical Functional Block (LFB) -- A template that represents a o Logical Functional Block (LFB) -- A template that represents a
fine-grained, logically separate aspects of FE processing. fine-grained, logically separate aspects of FE processing.
o ForCES Protocol -- The protocol used for communication
communication between CEs and FEs. This protocol does not apply
to CE-to-CE communication, 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, heartbeats)
and the control messages themselves.
o ForCES Protocol Layer (ForCES 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 as shown
below). Specifications of ForCES PL are defined in [RFC5810]
o ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
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, IP,
TCP, UDP, ATM, Ethernet, etc), and how to achieve and implement
reliability, security, etc.
o Forwarding Element (FE) - A logical entity that implements the o Forwarding Element (FE) - A logical entity that implements the
ForCES Protocol. FEs use the underlying hardware to provide per- ForCES Protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed by a CE via the ForCES packet processing and handling as directed by a CE via the ForCES
Protocol. Protocol.
o Control Element (CE) - A logical entity that implements the ForCES o Control Element (CE) - A logical entity that implements the ForCES
Protocol and uses it to instruct one or more FEs on how to process Protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of packets. CEs handle functionality such as the execution of
control and signaling protocols. control and signaling protocols.
skipping to change at page 3, line 44 skipping to change at page 3, line 21
association phase and is responsible for determining to which association phase and is responsible for determining to which
CE(s) an FE should communicate. This process is called CE CE(s) an FE should communicate. This process is called CE
discovery and may involve the FE manager learning the capabilities discovery and may involve the FE manager learning the capabilities
of available CEs. of available CEs.
o CE Manager - A logical entity that operates in the pre-association o CE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which FE(s) a CE phase and is responsible for determining to which FE(s) a CE
should communicate. This process is called FE discovery and may should communicate. This process is called FE discovery and may
involve the CE manager learning the capabilities of available FEs. involve the CE manager learning the capabilities of available FEs.
o ForCES Protocol -- The protocol used for communication
communication between CEs and FEs. This protocol does not apply
to CE-to-CE communication, 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, heartbeats)
and the control messages themselves.
o ForCES Protocol Layer (ForCES 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 as shown
below). Specifications of ForCES PL are defined in [RFC5810]
o ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
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, IP,
TCP, UDP, ATM, Ethernet, etc), and how to achieve and implement
reliability, security, etc.
2. Introduction 2. Introduction
Figure 1 illustrates a ForCES NE controlled by a set of redundant CEs Figure 1 illustrates a ForCES NE controlled by a set of redundant CEs
with CE1 being active and CE2 and CEN being a backup. with CE1 being active and CE2 and CEN being a backup.
----------------------------------------- -----------------------------------------
| ForCES Network Element | | ForCES Network Element |
| +-----------+ | | +-----------+ |
| | CEn | | | | CEn | |
| | (Backup) | | | | (Backup) | |
skipping to change at page 4, line 45 skipping to change at page 4, line 45
Ff: Interface between the FE Manager and an FE Ff: Interface between the FE Manager and an FE
Fl: Interface between the CE Manager and the FE Manager Fl: Interface between the CE Manager and the FE Manager
Fi/f: FE external interface Fi/f: FE external interface
Figure 1: ForCES Architecture Figure 1: ForCES Architecture
The ForCES architecture allows FEs to be aware of multiple CEs but The ForCES architecture allows FEs to be aware of multiple CEs but
enforces that only one CE be the master controller. This is known in 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 industry as 1+N redundancy. The master CE controls the FEs via
the ForCES protocol operating on the Fp interface. If the master CE the ForCES protocol operating on the Fp interface. If the master CE
becomes faulty, a backup CE takes over and NE operation continues. becomes faulty, i.e. crashes or loses connectivity, a backup CE takes
By definition, the current documented setup is known as cold-standby. over and NE operation continues. By definition, the current
The set of CEs controlling an FE is static and is passed to the FE by documented setup is known as cold-standby. The set of CEs
the FE Manager (FEM) via the Ff interface and to each CE by the CE controlling an FE is static and is passed to the FE by the FE Manager
Manager (CEM) in the Fc interface during the pre-association phase. (FEM) via the Ff interface and to each CE by the CE Manager (CEM) in
the Fc interface during the pre-association phase.
From an FE perspective, the knobs of control for a CE set are defined From an FE perspective, the knobs of control for a CE set are defined
by the FEPO LFB in [RFC5810], Appendix B. In Section 3.1 of this by the FEPO LFB in [RFC5810], Appendix B. In Section 3.1 of this
document we discuss further details of these knobs. document we discuss further details of these knobs.
2.1. Document Scope 2.1. Document Scope
It is assumed that the reader is aware of the ForCES architecture to It is assumed that the reader is aware of the ForCES architecture to
make sense of the changes being described in this document. This make sense of the changes being described in this document. This
document provides background information to set the context of the document provides background information to set the context of the
skipping to change at page 5, line 42 skipping to change at page 5, line 42
The NE recovery and availability is dependent on several time- The NE recovery and availability is dependent on several time-
sensitive metrics: sensitive metrics:
1. How fast the CE plane failure is detected by the FE. 1. How fast the CE plane failure is detected by the FE.
2. How fast a backup CE becomes operational. 2. How fast a backup CE becomes operational.
3. How fast the FEs associate with the new master CE. 3. How fast the FEs associate with the new master CE.
4. How fast the FEs recover their state and become operational. 4. How fast the FEs recover their 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 The design intent of the current [RFC5810] as well as this document
to meet the above goals are driven by desire for simplicity. to meet the above goals are driven by desire for simplicity.
To quantify the above criteria with the current prescribed ForCES CE To quantify the above criteria with the current prescribed ForCES CE
setup in [RFC5810]: setup in [RFC5810]:
1. How fast the FE side detects a CE failure is left undefined. To 1. How fast the FE side detects a CE failure is left undefined. To
illustrate an extreme scenario, we could have a human operator illustrate an extreme scenario, we could have a human operator
acting as the monitoring entity to detect faulty CEs. How fast acting as the monitoring entity to detect faulty CEs. How fast
such detection happens could be in the range of seconds to days. such detection happens could be in the range of seconds to days.
A more active monitor on the Fr interface could improve this A more active monitor on the Fp interface could improve this
detection. detection. Usually the FE will detect a CE failure either by the
TML if the Fp interface terminates or by the ForCES Protocol by
utilizing the ForCES heartbeat mechanism.
2. How fast the backup CE becomes operational is also currently out 2. How fast the backup CE becomes operational is also currently out
of scope. In the current setup, a backup CE need not be of scope. In the current setup, a backup CE need not be
operational at all (for example, to save power) and therefore it operational at all (for example, to save power) and therefore it
is feasible for a monitoring entity to boot up a backup CE after is feasible for a monitoring entity to boot up a backup CE after
it detects the failure of the master CE. In this document it detects the failure of the master CE. In this document
Section 4 we suggest that at least one backup CE be online so as Section 4 we suggest that at least one backup CE be online so as
to improve this metric. to improve this metric.
3. How fast an FE associates with new master CE is also currently 3. How fast an FE associates with new master CE is also currently
skipping to change at page 7, line 34 skipping to change at page 7, line 39
| Event Report (primary CE down) | | Event Report (primary CE down) |
4 |------------------------------------------------>| 4 |------------------------------------------------>|
| | | |
| State Update | | State Update |
5 |<----------------------------------------------->| 5 |<----------------------------------------------->|
Figure 2: CE Failover for Cold Standby Figure 2: CE Failover for Cold Standby
3.1.1. Cold Standby Interaction with ForCES Protocol 3.1.1. Cold Standby Interaction with ForCES Protocol
HA parametrization in an FE is driven by configuring the FE Protocol HA parameterization in an FE is driven by configuring the FE Protocol
Object (FEPO) LFB. Object (FEPO) LFB.
The FEPO CEID component identifies the current master CE and the The FEPO CEID component identifies the current master CE and the
component table BackupCEs identifies the configured backup CEs. The component table BackupCEs identifies the configured backup CEs. The
FEPO FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE FEPO FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE
Heartbeat policy help in detecting connectivity problems between an Heartbeat policy help in detecting connectivity problems between an
FE and CE. The CE Failover policy defines how the FE should react on FE and CE. The CE Failover policy defines how the FE should react on
a detected failure. The FEObject FEState component [RFC5812] defines a detected failure. The FEObject FEState component [RFC5812] defines
the operational forwarding status and control. The CE can turn off the operational forwarding status and control. The CE can turn off
the FE's forwarding operations by setting the FEState to AdminDisable the FE's forwarding operations by setting the FEState to AdminDisable
skipping to change at page 11, line 21 skipping to change at page 12, line 15
+ 2 (Associated) represents that the FE has successfully + 2 (Associated) represents that the FE has successfully
associated with the CE associated with the CE
+ 3 (IsMaster) represents that the FE has associated with + 3 (IsMaster) represents that the FE has associated with
the CE and is the master of the FE the CE and is the master of the FE
+ 4 (LostConnection) represents that the FE was associated + 4 (LostConnection) represents that the FE was associated
with the CE at one point but lost the connection with the CE at one point but lost the connection
+ 5 (Unreachable) represents the FE deems this CE + 5 (Unreachable) represents the FE deems this CE
unreachable. i.e the FE has tried over a period to connect unreachable. i.e., the FE has tried over a period to
to it but has failed. connect to it but has failed.
2. HAModeValues an unsigned char to specify selected HA mode. 2. HAModeValues an unsigned char to specify selected HA mode.
Special values are: Special values are:
+ 0 (No HA Mode) represents that the FE is not running in HA + 0 (No HA Mode) represents that the FE is not running in HA
mode mode
+ 1 (HA Mode - Cold Standby) represents that the FE is in HA + 1 (HA Mode - Cold Standby) represents that the FE is in HA
mode cold Standby mode cold Standby
+ and 2 (HA Mode - Hot Standby) represents that the FE is in + 2 (HA Mode - Hot Standby) represents that the FE is in HA
HA mode hot Standby mode hot Standby
3. Statistics, a complex structure, representing the 3. Statistics, a complex structure, representing the
communication statistics between the FE and CE. The communication statistics between the FE and CE. The
components are: components are:
+ RecvPackets representing the packet count received from + RecvPackets representing the packet count received from
the CE the CE
+ RecvBytes representing the byte count received from the CE + RecvBytes representing the byte count received from the CE
+ RecvErrPackets representing the erroneous packets received + RecvErrPackets representing the erroneous packets received
from the CE. This component logs badly formatted packets from the CE. This component logs badly formatted packets
as well as good packets sent to the FE by the CE to set as well as good packets sent to the FE by the CE to set
components whilst that CE is not the master. Erroneous components whilst that CE is not the master. Erroneous
packets are dropped(i.e not responded to). packets are dropped(i.e. not responded to).
+ RecvErrBytes representing the RecvErrPackets byte count + RecvErrBytes representing the RecvErrPackets byte count
received from the CE received from the CE
+ TxmitPackets representing the packet count transmitted to + TxmitPackets representing the packet count transmitted to
the CE the CE
+ TxmitErrPackets representing the error packet count + TxmitErrPackets representing the error packet count
transmitted to the CE. Typically these would be failures transmitted to the CE. Typically these would be failures
due to communication. due to communication.
skipping to change at page 13, line 6 skipping to change at page 13, line 52
CE (lowest table index) in the AllCEs table MUST be the first CE that CE (lowest table index) in the AllCEs table MUST be the first CE that
the FE will attempt to connect and associate with. If the FE fails the FE will attempt to connect and associate with. If the FE fails
to connect and associate with the first listed CE, it will attempt to to connect and associate with the first listed CE, it will attempt to
connect to the second CE and so forth, and cycles back to the connect to the second CE and so forth, and cycles back to the
beginning of the list until there is a successful association. The beginning of the list until there is a successful association. The
FE MUST associate with at least one CE. Upon a successful FE MUST associate with at least one CE. Upon a successful
association, a component of the FEPO LFB, specifically the CEID association, a component of the FEPO LFB, specifically the CEID
component, identifies the current associated master CE. component, identifies the current associated master CE.
While it would be much simpler to have the FE not respond to any While it would be much simpler to have the FE not respond to any
messages from a CE other than the master, in practise it has been 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 found to be useful to respond to queries and heartbeats from backup
CEs. For this reason, we allow backup CEs to issues queries to the CEs. For this reason, we allow backup CEs to issues queries to the
FE. Configuration messages (SET/DEL) from backup CEs MUST be dropped FE. Configuration messages (SET/DEL) from backup CEs MUST be dropped
by the FE and logged as received errors. by the FE and logged as received errors.
Asynchronous events that the master CE has subscribed to, as well as Asynchronous events that the master CE has subscribed to, as well as
heartbeats are sent to all associated-to CEs. Packet redirects heartbeats are sent to all associated-to CEs. Packet redirects
continue to be sent only to the master CE. The Heartbeat Interval, continue to be sent only to the master CE. The Heartbeat Interval,
the CE Heartbeat Policy (CEHB) and the FE Heartbeat Policy (FEHB) are the CE Heartbeat Policy (CEHB) and the FE Heartbeat Policy (FEHB) are
global for all CEs(and changed only by the master CE). global for all CEs(and changed only by the master CE).
skipping to change at page 14, line 22 skipping to change at page 15, line 20
association phase (Associated state). It is assumed that the master association phase (Associated state). It is assumed that the master
CE will communicate with other CEs within the NE for the purpose of 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 synchronization via the CE-CE interface. The CE-CE interface is out
of scope for this document. An election result amongst CEs may of scope for this document. An election result amongst CEs may
result in desire to change mastership to a different associated CE; result in desire to change mastership to a different associated CE;
at which point current assumed master CE will instruct the FE to use at which point current assumed master CE will instruct the FE to use
a different master CE. a different master CE.
FE CE#1 CE#2 ... CE#N FE CE#1 CE#2 ... CE#N
| | | | | | | |
| Association Estbalishment | | | | Association Establishment | | |
| Capabilities Exchange | | | | Capabilities Exchange | | |
1 |<------------------------->| | | 1 |<------------------------->| | |
| | | | | | | |
| State Update | | | | State Update | | |
2 |<------------------------->| | | 2 |<------------------------->| | |
| | | | | | | |
| Association Estbalishment | | | Association Establishment | |
| Capabilities Exchange | | | Capabilities Exchange | |
3I|<-------------------------------------->| | 3I|<-------------------------------------->| |
... ... ... ... ... ... ... ...
| Association Estbalishment,Capabilities Exchange | | Association Estbalishment,Capabilities Exchange |
3N|<----------------------------------------------->| 3N|<----------------------------------------------->|
| | | | | | | |
4 |<------------------------->| | | 4 |<------------------------->| | |
. . . . . . . .
4x|<------------------------->| | | 4x|<------------------------->| | |
| FAILURE | | | FAILURE | |
skipping to change at page 16, line 23 skipping to change at page 17, line 23
+----------------+---------+-----------+---------------+------------+ +----------------+---------+-----------+---------------+------------+
Logical Functional Block (LFB) Class Names and Class Identifiers Logical Functional Block (LFB) Class Names and Class Identifiers
The same rules applies as defined in [RFC5812] with the addition that The same rules applies as defined in [RFC5812] with the addition that
entries must provide the LFB version as a string. entries must provide the LFB version as a string.
Upon publication of this document, all current entries are assigned a Upon publication of this document, all current entries are assigned a
value of 1.0. value of 1.0.
New versions of already defined LFB, 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 should be
done by Class ID first and then by version.
This document introduces the FE Protocol Object version 1.1 as This document introduces the FE Protocol Object version 1.1 as
follows: follows:
+--------------+------------+---------+-----------------+-----------+ +--------------+------------+---------+-----------------+-----------+
| LFB Class | LFB Class | LFB | Description | Reference | | LFB Class | LFB Class | LFB | Description | Reference |
| Identifier | Name | Version | | | | Identifier | Name | Version | | |
+--------------+------------+---------+-----------------+-----------+ +--------------+------------+---------+-----------------+-----------+
| 2 | FE | 1.1 | Defines | This | | 2 | FE | 1.1 | Defines | This |
| | Protocol | | parameters for | document | | | Protocol | | parameters for | document |
| | Object | | the ForCES | | | | Object | | the ForCES | |
skipping to change at page 16, line 46 skipping to change at page 18, line 5
Logical Functional Block (LFB) Class Names and Class Identifiers Logical Functional Block (LFB) Class Names and Class Identifiers
6. Security Considerations 6. Security Considerations
Security consideration as defined in section 9 of [RFC5810] applies Security consideration as defined in section 9 of [RFC5810] applies
securing each CE-FE communication. Multiple CEs associated with the securing each CE-FE communication. Multiple CEs associated with the
same FE still require the same procedure to be followed on a per- same FE still require the same procedure to be followed on a per-
association basis. 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
message will be dropped. Thus the FE is secured from rogue or
malfunctioning CEs.
While CE-CE plane is outside current scope of ForCES, we recognize While CE-CE plane is outside current scope of ForCES, we recognize
that it may be subjected to attacks which may affect the CE-FE that it may be subjected to attacks which may affect the CE-FE
communication. communication.
The following considerations should be made: The following considerations should be made:
1. CEs should use secure communication channels between for 1. CEs should use secure communication channels between for
coordination and keeping of state at least to avoid connection of coordination and keeping of state at least to avoid connection of
malicious CEs. malicious CEs.
skipping to change at page 20, line 21 skipping to change at page 21, line 31
<synopsis> <synopsis>
The possible values of CE failover policy The possible values of CE failover policy
</synopsis> </synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>CEFailoverPolicy0</name> <name>CEFailoverPolicy0</name>
<synopsis> <synopsis>
The FE should stop functioning immediate and The FE should stop functioning immediate and
transition to the FE OperDisable state transition to the FE OperDisable state
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>CEFailoverPolicy1</name> <name>CEFailoverPolicy1</name>
<synopsis> <synopsis>
The FE should continue forwarding even without an The FE should continue forwarding even without an
associated CE for CEFTI. The FE goes to FE associated CE for CEFTI. The FE goes to FE
OperDisable when the CEFTI expires and no OperDisable when the CEFTI expires and no
association. Requires graceful restart support. association. Requires graceful restart support.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>FEHACapab</name> <name>FEHACapab</name>
<synopsis> <synopsis>
The supported HA features The supported HA features
skipping to change at page 27, line 16 skipping to change at page 28, line 26
</LFBLibrary> </LFBLibrary>
Authors' Addresses Authors' Addresses
Kentaro Ogawa Kentaro Ogawa
NTT Corporation NTT Corporation
3-9-11 Midori-cho 3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Email: ogawa.kentaro@lab.ntt.co.jp Email: k.ogawa@ntt.com
Weiming Wang Weiming Wang
Zhejiang Gongshang University Zhejiang Gongshang University
149 Jiaogong Road 149 Jiaogong Road
Hangzhou 310035 Hangzhou 310035
P.R.China P.R.China
Phone: +86-571-88057712 Phone: +86-571-88057712
Email: wmwang@mail.zjgsu.edu.cn Email: wmwang@mail.zjgsu.edu.cn
 End of changes. 22 change blocks. 
58 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/