< draft-wadhwa-rtgwg-bng-cups-protocol-requirements-01.txt   draft-wadhwa-rtgwg-bng-cups-protocol-requirements-02.txt >
rtgwg S. Wadhwa gwg S. Wadhwa
Internet Draft K. DeSmedt Internet Draft K. DeSmedt
Intended status: Informational P. Muley Intended status: Informational P. Muley
Expires: Jun 13, 2019 Nokia Expires: September 11, 2019 Nokia
R. Shinde R. Shinde
Reliance Jio Reliance Jio
J. Newton J. Newton
Vodafone Vodafone
R. Hoffman R. Hoffman
TELUS TELUS
S. Pani S. Pani
Juniper Networks Juniper Networks
Dec 14, 2018 March 11, 2019
Requirements for Protocol between Control and User Plane on BNG Requirements for Protocol between Control and User Plane on BNG
draft-wadhwa-rtgwg-bng-cups-protocol-requirements-01.txt draft-wadhwa-rtgwg-bng-cups-protocol-requirements-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 17, 2019. This Internet-Draft will expire on September 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 14, line 34 skipping to change at page 14, line 34
For security between CP and UP, Network Domain Security (NDS) as For security between CP and UP, Network Domain Security (NDS) as
defined in [TS33210] can be considered. As per NDS, the network can defined in [TS33210] can be considered. As per NDS, the network can
be split into security domains. Communication within a single be split into security domains. Communication within a single
security domain is considered secure, and protocols can operate security domain is considered secure, and protocols can operate
without any additional security. When communication has to cross without any additional security. When communication has to cross
security domains, then IPSEC can be used. security domains, then IPSEC can be used.
5. Management Interface Requirements 5. Management Interface Requirements
. The CP MUST provide a single point for management of entire . The CP MUST provide a single point for management of "CUPS BNG"
"CUPS BNG" to the operator. system to the operator.
. Management interface for the CUPS system MUST provide support . Management interface for the CUPS system MUST provide support
for both configuration of UPs, and state retrieval. for both configuration of UPs, and state retrieval. The
interface MUST minimally support BNG specific configuration and
state.
. Management interface MUST support transactional configuration . Management interface SHOULD support transactional configuration
from CP to UPs, based on a well-defined data schema. from CP to UPs, based on a well-defined data schema.
Transactional configuration may be achieved by editing a Transactional configuration may be achieved by editing a
candidate configuration on the UP which is subsequently candidate configuration on the UP which is subsequently
activated (commit) or by providing the whole transaction in a activated (commit) or by providing the whole transaction in a
single command. In case UP data-stores are used, it MUST be single command. In case UP data-stores are used, it MUST be
possible for the CP to lock a data-store for exclusive access. possible for the CP to lock a data-store for exclusive access.
. The management interface MUST support transaction confirmation, . The management interface SHOULD support transaction
where an unconfirmed transaction gets reverted automatically confirmation, where an unconfirmed transaction gets reverted
after a timeout even if the transaction succeeded. This is to automatically after a timeout even if the transaction
avoid configuration errors where a valid configuration breaks succeeded. This is to avoid configuration errors where a valid
communication between UP and CP, requiring on-site configuration breaks communication between UP and CP, requiring
intervention. on-site intervention.
. The management interface MUST support state retrieval based on . The management interface SHOULD support state retrieval based
a well-defined data schema. This includes retrieval for any on a well-defined data schema. This includes retrieval for any
state that is not signaled via the state control interface. state that is not signaled via the state control interface.
. The management interface MUST support unsolicited signaling of . The management interface SHOULD support unsolicited signaling
state changes (events) from UP to CP i.e. MUST provide of state changes (events) from UP to CP i.e. SHOULD provide
telemetry for events. Even while state changes are sent telemetry for events. Even while state changes are sent
unsolicited, the CP SHOULD be able to subscribe to a specific unsolicited, the CP SHOULD be able to subscribe to a specific
subset of state it is interested in. subset of state it is interested in.
. The management interface MUST provide security through an . The management interface MUST provide security through an
existing mechanism such as (D)TLS or IPSEC to guarantee existing mechanism such as (D)TLS or IPSEC to guarantee
confidentiality and authenticity and protect against replay and confidentiality and authenticity and protect against replay and
man in the middle attacks. man in the middle attacks.
6. IANA Considerations 6. IANA Considerations
 End of changes. 12 change blocks. 
20 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/