ANCP Rao. Shridhara Internet-Draft Cisco Systems Intended status: Informational Cassen. Alexandre Expires: April 21, 2010 Free October 18, 2009 Graceful ANCP restarts on NAS draft-ancp-restart-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 21, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes proposed extensions to the ANCP protocol to allow a graceful recovery of an ANCP session and associated Shridhara & Alexandre Expires April 21, 2010 [Page 1] Internet-Draft Graceful ANCP restarts October 2009 information after an existing session is reset. Such a reset may be due to a NAS restart , or a loss of connectivity between the NAS and the AN. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Detecting the loss of ANCP adjacency . . . . . . . . . . . 3 2.2. Loss of topological information . . . . . . . . . . . . . . 3 2.3. Loss of multicast information . . . . . . . . . . . . . . . 4 3. Proposed solutions . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Speeding up the detection of ANCP Adjacency loss . . . . . 4 3.2. Recovering topological information . . . . . . . . . . . . 5 3.3. Multicast use case . . . . . . . . . . . . . . . . . . . . 6 4. Sections TBD . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Shridhara & Alexandre Expires April 21, 2010 [Page 2] Internet-Draft Graceful ANCP restarts October 2009 1. Introduction This draft describes a set of mechanisms to optimize the detection of ANCP adjacency loss, the re-establishment of an ANCP adjacency and the recovery of the associated ANCP information. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. Problem Statement The ANCP base protocol, defined in[draft-ietf-ancp-protocol-06.txt], does not currently describe in any detail a mechanisms for detecting and recovering from the loss of an ANCP adjacency between the AN and the NAS. 2.1. Detecting the loss of ANCP adjacency The ANCP protocol currently relies on a keep-alive timer for detecting the loss of an adjacency. Since the keep-alive timer defaults to 10 seconds and the adjacency loss is triggered over a period spanning multiple times of the keep-alive timer(3 times by default), the achieved detection time is much longer than the time to detect the failure or closure of the TCP transport connection used by ANCP. If instead (or in addition to) the failure or closure of the underlying TCP connection is used as trigger for loss of ANCP adjacency, the ANCP reaction time can be much shorter. 2.2. Loss of topological information As per the behavior currently specified in the ANCP base protocol [draft-ancp], the AN sends topology information through Port-Up messages to a NAS after an adjacency is established. Such messages are however understood to be sent only for ports that actively change state, in terms of their modem train rate or operational status, after the establishment of the ANCP adjacency. In the event that the NAS looses topology information state (e.g due to a reload), or that the topology changes occur during the time the ANCP adjacency is down, this will result in the NAS holding an inaccurate view of the topological information and unable to apply the desired policies. Currently, ANCP does not provide for a mechanism by which the NAS can recover from this situation. Shridhara & Alexandre Expires April 21, 2010 [Page 3] Internet-Draft Graceful ANCP restarts October 2009 2.3. Loss of multicast information The ANCP multicast extensions draft [draft-ietf-ancp-mc-extensions-00.txt] describes a number of ANCP messages used for the control, authorization and reporting of multicast traffic on the AN. The loss of an ANCP adjacency, is also likely to lead to an inconsistency in the multicast information shared by the NAS and AN in the event that any of the devices lost or changed multicast information state during that time. More specifically, any multicast replication membership state that has been installed via ANCP may no longer be valid after the ANCP adjacency is recovered. This may be due to either the AN or NAS resetting or changes of policy during the time the ANCP adjacency is down. This issue also clearly affects the correct operation of the system, likely leading to incorrect policy decisions and also multicast replication state. 3. Proposed solutions 3.1. Speeding up the detection of ANCP Adjacency loss Based on the inherent binding of ANCP to the TCP transport, by using the TCP socket state it is possible for the AN to detect a failure in transport of the ANCP adjacency before the ANCP keepalive timer expires. As such we propose that ANCP implementations monitor the TCP socket state and on detecting an active ANCP transport socket transitioning to the CLOSED state they reset the ANCP adjacency state for the node corresponding to the TCP socket. The following figure shows an exemplary sequence of events along with TCP socket states. The following figure shows an exemplary sequence of events along with TCP socket states. Shridhara & Alexandre Expires April 21, 2010 [Page 4] Internet-Draft Graceful ANCP restarts October 2009 _____ _____ | | | | | AN | | NAS | |_____| |_____| ^ ^ |--->--->--->-------------- SYN -------------->--->--->---| SYN-SENT |---<---<---<------------ SYN/ACK ------------<---<---<---| SYN-RCVD |--->--->--->-------------- ACK -------------->--->--->---| ESTD ESTD |<--------------------- ANCP ESTAB ---------------------> | | ... | | system restart ---> ^ | | |--->--->--->-------------- PSH -------------->--->--->---| (Abort) |---<---<---<-------------- RST --------------<---<---<---| CLOSED | | Figure 1 Following the AN reaching the CLOSED TCP socket state, the corresponding ANCP adjacency is to be reset by the AN and an attempt to re- establish the TCP connection initiated. In other words, the CLOSED TCP socket state is to be interpreted as an ANCP link down event. 3.2. Recovering topological information In order to minimize the need for protocol changes, including new capabilities, we propose the following solution. Each time ANCP establishes or re-establishes an adjacency, the AN MUST send Port-Up messages for all ports that are currently active on the AN. Initial Port_UP messages (Derived from all active ports) <------------- 1. NAS --------------------------- Access Node Figure 2 The above behavior of the AN is proposed to be mandated as part of the ANCP protocol specification. Shridhara & Alexandre Expires April 21, 2010 [Page 5] Internet-Draft Graceful ANCP restarts October 2009 3.3. Multicast use case When ANCP adjacency goes down due to NAS restarts, NAS is no longer synchronized with AN multicast membership. Reconciling multicast information consistency is a bit more complicated due to the fact that both the AN and NAS are in their own ways producers and consumers of such information. The mechanism to reconcile authorization and configuration state (e.g delegated bandwidth) on the AN needs further study. In terms of reconciling active multicast group membership on the AN, we propose that upon the re-establishment of the ANCP adjacency, the NAS issues an all port Multicast flow report query to the AN to obtain a picture of the multicast flow membership state present on the AN. Based on the then received multicast flow report the NAS would, when configured to do so, re-run any conditional access policy checks in order to determine whether the reported flows are still in line with the active policies. For any flows that are found to be in violation of such policies, the NAS would then issue a Multicast-Replication-Ctrl message requesting the deletion of the flow by the AN. This reconciliation process is illustrated in Figure 3 and does not appear to require protocol modifications beyond what is specified in [draft-ietf-ancp-mc-extensions-00.txt]. Shridhara & Alexandre Expires April 21, 2010 [Page 6] Internet-Draft Graceful ANCP restarts October 2009 Reconciling Multicast data _____ _____ | | | | | AN | | NAS | |_____| |_____| ^ ^ | | |<--------------------- ANCP ESTAB --------------------->| | ... | | system restart (loss of synch) --> ^ | | |<--------------------- ANCP ESTAB --------------------->| | | |---<---<---<- Multicast Flow Report Request -<---<---<--| | | |--->--->--->- Multicast Flow Report Response ->--->-->--| | | | Conditional Access check -->(*) | ... | |---<---<---<-- Multicast-Replication-Crl --<---<---<---| | (Target,delete,Flow 1) | | ... | (*) NAS performs a conditional access and admission control checks. If flow reported is no longer allowed for target then NAS send a Multicast-Replication-Crl delete message to AN (Flow 1 in figure 3). Figure 3 Based on the above description the following functional requirement may be laid down to describe the expected NAS and AN behaviors: Following the establishment or re-establishment of an ANCP adjacency with transactional multicast capability, the NAS MUST issue a Multicast Flow Report request message requesting the status for all ports. Upon receiving the multicast flow report response from the AN, NAS MUST perform a conditional access check on the reported multicast flows and use the outcome to drive an flow deletion requests by means of Multicast Replication Control messages (0x01). 4. Sections TBD The following procedure needs to be described: 1. The case when AN has the Multicast Bandwidth Delegation control enabled, and either NAS or AN restarts (or ANCP adjacency restarts). How to reconcile the bandwidth usage by each flow needs to be described. Shridhara & Alexandre Expires April 21, 2010 [Page 7] Internet-Draft Graceful ANCP restarts October 2009 5. Acknowledgements The authors would like to acknowledge Wojciech Dec and Francois Le Faucheur for providing inputs and guiding them in editing this document, Aniruddha A for his feedback. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [draft-ietf-ancp-mc-extensions-00.txt] Le Faucheur, et al., F., "Additional Multicast Control Extensions for ANCP", 2009. [draft-ietf-ancp-protocol-06.txt] Wadhwa, et al., S., "Protocol for Access Node Control Mechanism in Broadband Networks", 2009. 8.2. Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Appendix A. Additional Stuff This becomes the Appendix. Shridhara & Alexandre Expires April 21, 2010 [Page 8] Internet-Draft Graceful ANCP restarts October 2009 Authors' Addresses Shridhara Rao Cisco Systems Cessna Business Park Bangalore, Karnataka 560 087 India Phone: +91 80 4426 0220 Email: shrirao@cisco.com Alexandre Cassen Free 8, Rue de la Ville l Eveque Paris, 75008 France Email: acassen@freebox.fr Shridhara & Alexandre Expires April 21, 2010 [Page 9]