]> Cisco Systems

Cessna Business Park Bangalore Karnataka 560 087 India +91 80 4426 0220 shrirao@cisco.com

Free

8, Rue de la Ville l Eveque Paris 75008 France acassen@freebox.fr

General ANCP template 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.

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.

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.

The ANCP base protocol, defined in, 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.

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.

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.

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.

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.

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

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.

The above behavior of the AN is proposed to be mandated as part of the ANCP protocol specification.

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

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

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

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.

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.

This memo includes no request to IANA.

All drafts are required to have a security considerations section. See RFC 3552 for a guide.

&RFC2119; &RFC3552;

This becomes the Appendix.