Graceful ANCP restarts on NAS
draft-ancp-restart-00

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 20, 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 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
    1.1.  Requirements Language
2.  Problem Statement
    2.1.  Detecting the loss of ANCP adjacency
    2.2.  Loss of topological information
    2.3.  Loss of multicast information
3.  Proposed solutions
    3.1.  Speeding up the detection of ANCP Adjacency loss
    3.2.  Recovering topological information
    3.3.  Multicast use case
4.  Sections TBD
5.  Acknowledgements
6.  IANA Considerations
7.  Security Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Additional Stuff
§  Authors' Addresses

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Problem Statement

The ANCP base protocol, defined in[draft‑ietf‑ancp‑protocol‑06.txt] (Wadhwa, et al., S., “Protocol for Access Node Control Mechanism in Broadband Networks,” 2009.), 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 30 seconds and the adjacency loss is triggered over a period spanning multiple times of the keep-alive timer, 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. Therefore, we recommend that the state of the underlying TCP connection be used as a trigger for loss of ANCP adjacency.

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.

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.

   _____                                                     _____
   |     |                                                   |     |
   | AN  |                                                   | NAS |
   |_____|                                                   |_____|
      ^                                                         ^
      |--->--->--->-------------- SYN -------------->--->--->---|
   SYN-SENT
      |---<---<---<------------ SYN/ACK ------------<---<---<---|
                                                          SYN-RCVD
      |--->--->--->-------------- ACK -------------->--->--->---|
  ESTD                                                       ESTD
      |<--------------------- ANCP ESTAB ---------------------> |
      |                           ...                           |
      |                                     system restart ---> ^
      |                                                         |
      |--->--->--->-------------- PSH -------------->--->--->---|
                                                             (Abort)
      |---<---<---<-------------- RST --------------<---<---<---|
   CLOSED
      |                                                         |

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 should 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

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. (Here we are not describing the case when AN itself restarts, that is TBD) 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].

            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).

4.  Sections TBD

The following procedures are still 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). 2. The Multicast reconciliation procedure presented in this document applies to NAS restarts only; it doesn't cover the case where AN restarts.

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 (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) [RFC3552] for a guide.

8.  References

8.1. Normative References

8.2. Informative References

Appendix A.  Additional Stuff

This becomes the Appendix.

Authors' Addresses