draft-ietf-forces-ceha-09.txt   draft-ietf-forces-ceha-10.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: May 24, 2014 E. Haleplidis Expires: June 13, 2014 E. Haleplidis
University of Patras University of Patras
J. Hadi Salim J. Hadi Salim
Mojatatu Networks Mojatatu Networks
November 20, 2013 December 10, 2013
ForCES Intra-NE High Availability ForCES Intra-NE High Availability
draft-ietf-forces-ceha-09 draft-ietf-forces-ceha-10
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 May 24, 2014. This Internet-Draft will expire on June 13, 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . 10 3.1.2. Responsibilities for HA . . . . . . . . . . . . . . . 10
4. CE HA Hot Standby . . . . . . . . . . . . . . . . . . . . . . 11 4. CE HA Hot Standby . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Changes to the FEPO model . . . . . . . . . . . . . . . . 11 4.1. Changes to the FEPO model . . . . . . . . . . . . . . . . 11
4.2. FEPO processing . . . . . . . . . . . . . . . . . . . . . 13 4.2. FEPO processing . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. New FEPO version . . . . . . . . . . . . . . . . . . 19 Appendix A. New FEPO version . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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:
skipping to change at page 9, line 5 skipping to change at page 9, line 5
recovery of connection state. recovery of connection state.
The FE connects to the CE specified on FEPO CEID component. If it The FE connects to the CE specified on FEPO CEID component. If it
fails to connect to the defined CE, it moves it to the bottom of 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 table BackupCEs and sets its CEID component to be the first CE
retrieved from table BackupCEs. The FE then attempts to associate retrieved from table BackupCEs. The FE then attempts to associate
with the CE designated as the new primary CE. The FE continues with the CE designated as the new primary CE. The FE continues
through this procedure until it successfully connects to one of the through this procedure until it successfully connects to one of the
CEs or until the CE Failover Timeout Interval (CEFTI) expires. CEs or until the CE Failover Timeout Interval (CEFTI) expires.
FE tries to associate FE tries to associate
+-->-----+ +-->-----+
| | | |
(CE changes master || | | (CE changes master || | |
CE issues Teardown || +---+--------v----+ CE issues Teardown || +---+--------v----+
Lost association) && | Pre-Association | Lost association) && | Pre-Association |
CE failover policy = 0 | (Association | CE failover policy = 0 | (Association |
+------------>-->-->| in +<----+ +------------>-->-->| in +<----+
| | progress) | | | | progress) | |
| | | | | | | |
| +--------+--------+ | | +--------+--------+ |
| CE Association | | CEFTI | CE Association | | CEFTI
| Response V | timer | Response V | timer
| +------------------+ | expires | +------------------+ | expires
| |FE issue CEPrimaryDown ^ | |FE issue CEPrimaryDown ^
| V | | V |
+-+-----------+ +------+-----+ +-+-----------+ +------+-----+
| | (CE changes master || | Not | | | (CE changes master || | Not |
| | CE issues Teardown || | Associated | | | CE issues Teardown || | Associated |
| | Lost association) && | +->---+ | | Lost association) && | +->---+
| Associated | CE Failover Policy = 1 |(May | FE | | Associated | CE Failover Policy = 1 |(May | FE |
| | | Continue | try v | | | Continue | try v
| |-------->------->------>| Forwarding)| assn| | |-------->------->------>| Forwarding)| assn|
| | Start CEFTI timer | |-<---+ | | Start CEFTI timer | |-<---+
| | | | | | | |
+-------------+ +-------+-----+ +-------------+ +-------+-----+
^ | ^ |
| Successful V | Successful V
| Association | | Association |
| Setup | | Setup |
| (Cancel CEFTI Timer) | | (Cancel CEFTI Timer) |
+_________________________________________+ +_________________________________________+
FE issue CEPrimaryDown event FE issue CEPrimaryDown event
Figure 3: FE State Machine considering HA Figure 3: FE State Machine considering HA
There are several events that trigger mastership changes: The master There are several events that trigger mastership changes: The master
CE may issue a mastership change (by changing the CEID component), or CE may issue a mastership change (by changing the CEID component), or
teardown an existing association; and last, connectivity may be lost teardown an existing association; and last, connectivity may be lost
between the CE and FE. between the CE and FE.
When communication fails between the FE and CE (which can be caused When communication fails between the FE and CE (which can be caused
by either the CE or link failure but not FE related), either the TML by either the CE or link failure but not FE related), either the TML
skipping to change at page 15, line 18 skipping to change at page 16, line 5
Once the FE has associated with a master CE it moves to the post- Once the FE has associated with a master CE it moves to the post-
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 Establishment | | | | Association Establishment | | |
| Capabilities Exchange | | | | Capabilities Exchange | | |
1 |<------------------------->| | | 1 |<------------------------->| | |
| | | | | | | |
| State Update | | | | State Update | | |
2 |<------------------------->| | | 2 |<------------------------->| | |
| | | | | | | |
| Association Establishment | | | Association Establishment | |
| Capabilities Exchange | | | Capabilities Exchange | |
3I|<-------------------------------------->| | 3I|<-------------------------------------->| |
... ... ... ... ... ... ... ...
| Association Estbalishment,Capabilities Exchange | | Association Estbalishment,Capabilities Exchange |
3N|<----------------------------------------------->| 3N|<----------------------------------------------->|
| | | | | | | |
4 |<------------------------->| | | 4 |<------------------------->| | |
. . . . . . . .
4x|<------------------------->| | | 4x|<------------------------->| | |
| FAILURE | | | FAILURE | |
| | | | | | | |
| Event Report (LastCEID changed) | | | Event Report (LastCEID changed) | |
5 |--------------------------------------->|------->| 5 |--------------------------------------->|------->|
| Event Report (CE#2 is new master) | | | Event Report (CE#2 is new master) | |
6 |--------------------------------------->|------->| 6 |--------------------------------------->|------->|
| | | | | |
7 |<-------------------------------------->| | 7 |<-------------------------------------->| |
. . . . . . . .
7x|<-------------------------------------->| | 7x|<-------------------------------------->| |
. . . . . . . .
Figure 5: CE Failover for Hot Standby Figure 5: CE Failover for Hot Standby
While in the post-association phase, if the CE Failover Policy is set While in the post-association phase, if the CE Failover Policy is set
to 1 and HAMode set to 2 (HotStandby) then the FE, after successfully to 1 and HAMode set to 2 (HotStandby) then the FE, after successfully
associating with the master CE, MUST attempt to connect and associate associating with the master CE, MUST attempt to connect and associate
with all the CEs that it is aware of. Figure 5 steps #1 and #2 with all the CEs that it is aware of. Figure 5 steps #1 and #2
illustrates the FE associating with CE#1 as the master and then illustrates the FE associating with CE#1 as the master and then
proceeding to steps #3I to #3N the association with backup CEs CE#2 proceeding to steps #3I to #3N the association with backup CEs CE#2
to CE#N. If the FE fails to connect or associate with some CEs, the to CE#N. If the FE fails to connect or associate with some CEs, the
skipping to change at page 17, line 8 skipping to change at page 17, line 40
5. IANA Considerations 5. IANA Considerations
Following the policies outlined in "Guidelines for Writing an IANA Following the policies outlined in "Guidelines for Writing an IANA
Considerations Section in RFCs" [RFC5226], the Logical Functional Considerations Section in RFCs" [RFC5226], the Logical Functional
Block (LFB) Class Names and Class Identifiers namespaces is updated. Block (LFB) Class Names and Class Identifiers namespaces is updated.
A new column, LFB version, is added to the table after the LFB Class A new column, LFB version, is added to the table after the LFB Class
Name. The table now reads as follows: Name. The table now reads as follows:
+----------------+---------+-----------+---------------+------------+ +----------------+------------+-----------+-------------+-----------+
| LFB Class | LFB | LFB | Description | Reference | | LFB Class | LFB Class | LFB | Description | Reference |
| Identifier | Class | Version | | | | Identifier | Name | Version | | |
| | Name | | | | +----------------+------------+-----------+-------------+-----------+
+----------------+---------+-----------+---------------+------------+ +----------------+------------+-----------+-------------+-----------+
+----------------+---------+-----------+---------------+------------+
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 New versions of already defined LFB, MUST NOT remove the previous
version entries. version entries.
It would make sense to have LFB versions to appear in sequence in the 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 registry. The table SHOULD be sorted, and the shorting should be
done by Class ID first and then by version. 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 parameters | This |
| | Protocol | | parameters for | document | | | Protocol | | for the ForCES | document |
| | Object | | the ForCES | | | | Object | | protocol operation | |
| | | | protocol | | +------------+-----------+---------+--------------------+-----------+
| | | | operation | |
+--------------+------------+---------+-----------------+-----------+
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 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 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 messages will be dropped. Thus the FE is secured from rogue CEs that
malfunctioning CEs. are attempting to associate with it.
CE implementers should have in mind that once associated the FE
cannot distinguish whether the CE has been compromised or
malfunctioning while not losing connectivity. Securing the CE is out
of scope of this document.
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.
 End of changes. 11 change blocks. 
91 lines changed or deleted 93 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/