Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)
RFC 4744

Network Working Group                                            E. Lear
Request for Comments: 4744                                 Cisco Systems
Category: Standards Track                                     K. Crozier
                                                           December 2006

                    Using the NETCONF Protocol over
             the Blocks Extensible Exchange Protocol (BEEP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   This document specifies an application protocol mapping for the
   Network Configuration Protocol (NETCONF) over the Blocks Extensible
   Exchange Protocol (BEEP).

Table of Contents

   1. Introduction ....................................................2
      1.1. Why BEEP? ..................................................2
   2. BEEP Transport Mapping ..........................................2
      2.1. NETCONF Session Establishment ..............................2
      2.2. Starting a Channel for NETCONF .............................4
      2.3. NETCONF Session Usage ......................................5
      2.4. NETCONF Session Teardown ...................................5
      2.5. BEEP Profile for NETCONF ...................................6
   3. Security Considerations .........................................6
   4. IANA Considerations .............................................7
   5. Acknowledgments .................................................7
   6. References ......................................................8
      6.1. Normative References .......................................8
      6.2. Informative References .....................................8

Lear & Crozier              Standards Track                     [Page 1]
RFC 4744                   NETCONF over BEEP               December 2006

1.  Introduction

   The NETCONF protocol [1] defines a simple mechanism through which a
   network device can be managed.  NETCONF is designed to be usable over
   a variety of application protocols.  This document specifies an
   application protocol mapping for NETCONF over the Blocks Extensible
   Exchange Protocol (BEEP) [7].

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

1.1.  Why BEEP?

   Use of BEEP is natural as an application protocol for transport of
   XML.  As a peer-to-peer protocol, BEEP provides an easy way to
   implement NETCONF, no matter which side of the connection was the
   initiator.  This "bidirectionality" allows for either manager or
   agent to initiate a connection.  This is particularly important to
   support large numbers of intermittently connected devices, as well as
   those devices that must reverse the management connection in the face
   of firewalls and network address translators (NATs).

   BEEP makes use of the Simple Authentication and Security Layer (SASL)
   [3].  The SASL profile used by BEEP allows for a simple and direct
   mapping to the existing security model for command line interface
   (CLI), while Transport Layer Security (TLS) [4] provides a strong,
   well-tested encryption mechanism with either server or server and
   client-side authentication.

2.  BEEP Transport Mapping

   All NETCONF over BEEP implementations MUST implement the profile and
   functional mapping between NETCONF and BEEP as described below.

   For purposes of this document, a manager is a NETCONF client, and an
   agent is a NETCONF server.  Use of client/server language in BEEP is
   avoided because of the common notion that in networking clients
   connect to servers.

2.1.  NETCONF Session Establishment

   Managers may be either BEEP listeners or initiators.  Similarly,
   agents may be either listeners or initiators.  To establish a
   connection, the initiator connects to the listener on TCP port 831.
   Thus, the initial exchange takes place without regard to whether a
   manager or the agent is the initiator.  After the transport
   connection is established, as greetings are exchanged, they SHOULD

Lear & Crozier              Standards Track                     [Page 2]