Diff: rfc8921v2.txt - rfc8921.txt

	rfc8921v2.txt	rfc8921.txt

	skipping to change at line 1352 ¶	skipping to change at line 1352 ¶

	9.1.9. SERVICE_DESCRIPTION	9.1.9. SERVICE_DESCRIPTION

	This document defines a machinery to negotiate any aspect subject to	This document defines a machinery to negotiate any aspect subject to
	negotiation. Service clauses that are under negotiation are conveyed	negotiation. Service clauses that are under negotiation are conveyed
	using this attribute.	using this attribute.

	The structure of the connectivity provisioning clauses is provided in	The structure of the connectivity provisioning clauses is provided in
	the following subsection.	the following subsection.


	9.1.9.1. CONNECTIVITY_PROVISIONING_DOCUMENT	9.1.9.1. CPD

	The RBNF format of the CPD is shown in Figure 10.	The RBNF format of the CPD is shown in Figure 10.


	<CONNECTIVITY_PROVISIONING_DOCUMENT> ::=	<CPD> ::= <Connectivity Provisioning Component> ...
	<Connectivity Provisioning Component> ...
	<Connectivity Provisioning Component> ::=	<Connectivity Provisioning Component> ::=
	<CONNECTIVITY_PROVISIONING_PROFILE> ...	<CONNECTIVITY_PROVISIONING_PROFILE> ...
	<CONNECTIVITY_PROVISIONING_PROFILE> ::=	<CONNECTIVITY_PROVISIONING_PROFILE> ::=
	<Customer Nodes Map>	<Customer Nodes Map>
	<SCOPE>	<SCOPE>
	<QoS Guarantees>	<QoS Guarantees>
	<Availability>	<Availability>
	<CAPACITY>	<CAPACITY>
	<Traffic Isolation>	<Traffic Isolation>
	<Conformance Traffic>	<Conformance Traffic>

	skipping to change at line 1487 ¶	skipping to change at line 1486 ¶
	9.2.1. QUOTATION	9.2.1. QUOTATION

	The format of the QUOTATION message is shown below:	The format of the QUOTATION message is shown below:

	<QUOTATION Message> ::= <VERSION>	<QUOTATION Message> ::= <VERSION>
	<METHOD_CODE>	<METHOD_CODE>
	<SEQUENCE_NUMBER>	<SEQUENCE_NUMBER>
	<TRANSACTION_ID>	<TRANSACTION_ID>
	<CUSTOMER_ORDER_IDENTIFIER>	<CUSTOMER_ORDER_IDENTIFIER>
	[<EXPECTED_RESPONSE_TIME>]	[<EXPECTED_RESPONSE_TIME>]

	<REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT>	<REQUESTED_CPD>
	[<INFORMATION_ELEMENT>...]	[<INFORMATION_ELEMENT>...]

	A QUOTATION message must include an order identifier that is	A QUOTATION message must include an order identifier that is
	generated by the client (CUSTOMER_ORDER_IDENTIFIER). Because several	generated by the client (CUSTOMER_ORDER_IDENTIFIER). Because several
	orders can be issued to several servers, the QUOTATION message must	orders can be issued to several servers, the QUOTATION message must
	also include a Transaction-ID.	also include a Transaction-ID.

	The message may include an EXPECTED_RESPONSE_TIME, which indicates by	The message may include an EXPECTED_RESPONSE_TIME, which indicates by
	when the client expects to receive an offer from the server. The	when the client expects to receive an offer from the server. The
	QUOTATION message must also include a requested service description	QUOTATION message must also include a requested service description

	skipping to change at line 1599 ¶	skipping to change at line 1598 ¶
	The format of the OFFER message is shown below:	The format of the OFFER message is shown below:

	<OFFER Message> ::= <VERSION>	<OFFER Message> ::= <VERSION>
	<METHOD_CODE>	<METHOD_CODE>
	<SEQUENCE_NUMBER>	<SEQUENCE_NUMBER>
	<TRANSACTION_ID>	<TRANSACTION_ID>
	<CUSTOMER_ORDER_IDENTIFIER>	<CUSTOMER_ORDER_IDENTIFIER>
	<PROVIDER_ORDER_IDENTIFIER>	<PROVIDER_ORDER_IDENTIFIER>
	<NONCE>	<NONCE>
	<VALIDITY_OFFER_TIME>	<VALIDITY_OFFER_TIME>

	<OFFERED_CONNECTIVITY_PROVISIONING_DOCUMENT>	<OFFERED_CPD>
	[<INFORMATION_ELEMENT>...]	[<INFORMATION_ELEMENT>...]

	The server answers a QUOTATION request received from the client with	The server answers a QUOTATION request received from the client with
	an OFFER message. The offer will be considered to be rejected by the	an OFFER message. The offer will be considered to be rejected by the
	client if no confirmation (i.e., an ACCEPT message sent by the	client if no confirmation (i.e., an ACCEPT message sent by the
	client) is received by the server before the expiration of the	client) is received by the server before the expiration of the
	validity time.	validity time.

	The server may include ACTIVATION_TYPE to indicate whether the offer	The server may include ACTIVATION_TYPE to indicate whether the offer
	is about a permanent or scheduled activation type. The message may	is about a permanent or scheduled activation type. The message may

	skipping to change at line 1627 ¶	skipping to change at line 1626 ¶

	The format of the ACCEPT message is shown below:	The format of the ACCEPT message is shown below:

	<ACCEPT Message> ::= <VERSION>	<ACCEPT Message> ::= <VERSION>
	<METHOD_CODE>	<METHOD_CODE>
	<SEQUENCE_NUMBER>	<SEQUENCE_NUMBER>
	<TRANSACTION_ID>	<TRANSACTION_ID>
	<CUSTOMER_ORDER_IDENTIFIER>	<CUSTOMER_ORDER_IDENTIFIER>
	<PROVIDER_ORDER_IDENTIFIER>	<PROVIDER_ORDER_IDENTIFIER>
	<NONCE>	<NONCE>

	<ACCEPTED_CONNECTIVITY_PROVISIONING_DOCUMENT>	<ACCEPTED_CPD>
	[<INFORMATION_ELEMENT>...]	[<INFORMATION_ELEMENT>...]

	This message is used by a client to confirm the acceptance of an	This message is used by a client to confirm the acceptance of an
	offer received from a server. The fields of this message must be	offer received from a server. The fields of this message must be
	copied from the received OFFER message. This message should not be	copied from the received OFFER message. This message should not be
	sent after the validity time of the offer expires, as indicated by	sent after the validity time of the offer expires, as indicated by
	the server (Section 9.2.3).	the server (Section 9.2.3).

	9.2.5. DECLINE	9.2.5. DECLINE


	skipping to change at line 1703 ¶	skipping to change at line 1702 ¶

	The format of the ACK message is shown below:	The format of the ACK message is shown below:

	<ACK Message> ::= <VERSION>	<ACK Message> ::= <VERSION>
	<METHOD_CODE>	<METHOD_CODE>
	<SEQUENCE_NUMBER>	<SEQUENCE_NUMBER>
	<TRANSACTION_ID>	<TRANSACTION_ID>
	<CUSTOMER_ORDER_IDENTIFIER>	<CUSTOMER_ORDER_IDENTIFIER>
	<PROVIDER_ORDER_IDENTIFIER>	<PROVIDER_ORDER_IDENTIFIER>
	[<EXPECTED_RESPONSE_TIME>]	[<EXPECTED_RESPONSE_TIME>]

	[<CONNECTIVITY_PROVISIONING_DOCUMENT>]	[<CPD>]
	[<INFORMATION_ELEMENT>...]	[<INFORMATION_ELEMENT>...]

	This message is issued by the server to close a CPNP transaction or	This message is issued by the server to close a CPNP transaction or
	by a client to grant more negotiation time to the server.	by a client to grant more negotiation time to the server.

	This message is sent by the server as a response to an ACCEPT,	This message is sent by the server as a response to an ACCEPT,
	WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message	WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message
	must include the copy of the service description (i.e., CPD for	must include the copy of the service description (i.e., CPD for
	connectivity services) as stored by the server. In particular, the	connectivity services) as stored by the server. In particular, the
	following considerations are taken into account for connectivity	following considerations are taken into account for connectivity

	skipping to change at line 1743 ¶	skipping to change at line 1742 ¶

	9.2.7. CANCEL	9.2.7. CANCEL

	The format of the CANCEL message is shown below:	The format of the CANCEL message is shown below:

	<CANCEL Message> ::= <VERSION>	<CANCEL Message> ::= <VERSION>
	<METHOD_CODE>	<METHOD_CODE>
	<SEQUENCE_NUMBER>	<SEQUENCE_NUMBER>
	<TRANSACTION_ID>	<TRANSACTION_ID>
	<CUSTOMER_ORDER_IDENTIFIER>	<CUSTOMER_ORDER_IDENTIFIER>

	[<CONNECTIVITY_PROVISIONING_DOCUMENT>]	[<CPD>]

	The client can issue a CANCEL message at any stage during the CPNP	The client can issue a CANCEL message at any stage during the CPNP
	negotiation process before an agreement is reached. The	negotiation process before an agreement is reached. The
	CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID are used by the server	CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID are used by the server
	as keys to find the corresponding order. If a quotation order	as keys to find the corresponding order. If a quotation order
	matches, the server changes the state of this quotation order to	matches, the server changes the state of this quotation order to
	"Cancelled" and then returns an ACK with a copy of the Requested CPD	"Cancelled" and then returns an ACK with a copy of the Requested CPD
	to the requesting client.	to the requesting client.

	If no quotation order is found, the server returns a FAIL message to	If no quotation order is found, the server returns a FAIL message to

	skipping to change at line 1767 ¶	skipping to change at line 1766 ¶

	The format of the WITHDRAW message is shown below:	The format of the WITHDRAW message is shown below:

	<WITHDRAW Message> ::= <VERSION>	<WITHDRAW Message> ::= <VERSION>
	<METHOD_CODE>	<METHOD_CODE>
	<SEQUENCE_NUMBER>	<SEQUENCE_NUMBER>
	<TRANSACTION_ID>	<TRANSACTION_ID>
	<CUSTOMER_ORDER_IDENTIFIER>	<CUSTOMER_ORDER_IDENTIFIER>
	<PROVIDER_ORDER_IDENTIFIER>	<PROVIDER_ORDER_IDENTIFIER>
	<NONCE>	<NONCE>

	[<ACCEPTED_CONNECTIVITY_PROVISIONING_DOCUMENT>]	[<ACCEPTED_CPD>]
	[<INFORMATION_ELEMENT>...]	[<INFORMATION_ELEMENT>...]

	This message is used to withdraw an offer already accepted by the	This message is used to withdraw an offer already accepted by the
	Customer. Figure 14 shows a typical usage of this message.	Customer. Figure 14 shows a typical usage of this message.

	+------+ +------+	+------+ +------+
	\|Client\| \|Server\|	\|Client\| \|Server\|
	+------+ +------+	+------+ +------+
	\|============WITHDRAW(CPD)===========>\|	\|============WITHDRAW(CPD)===========>\|
	\|<============PROCESSING==============\|	\|<============PROCESSING==============\|

	skipping to change at line 1805 ¶	skipping to change at line 1804 ¶
	The format of the UPDATE message is shown below:	The format of the UPDATE message is shown below:

	<UPDATE Message> ::= <VERSION>	<UPDATE Message> ::= <VERSION>
	<METHOD_CODE>	<METHOD_CODE>
	<SEQUENCE_NUMBER>	<SEQUENCE_NUMBER>
	<TRANSACTION_ID>	<TRANSACTION_ID>
	<CUSTOMER_ORDER_IDENTIFIER>	<CUSTOMER_ORDER_IDENTIFIER>
	<PROVIDER_ORDER_IDENTIFIER>	<PROVIDER_ORDER_IDENTIFIER>
	<NONCE>	<NONCE>
	<EXPECTED_RESPONSE_TIME>	<EXPECTED_RESPONSE_TIME>

	<REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT>	<REQUESTED_CPD>
	[<INFORMATION_ELEMENT>...]	[<INFORMATION_ELEMENT>...]

	This message is sent by the CPNP client to update an existing service	This message is sent by the CPNP client to update an existing service
	agreement (e.g., Accepted CPD). The UPDATE message must include the	agreement (e.g., Accepted CPD). The UPDATE message must include the
	same CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE	same CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE
	as those used when creating the order. The CPNP client includes a	as those used when creating the order. The CPNP client includes a
	new service description (e.g., Updated CPD) that integrates the	new service description (e.g., Updated CPD) that integrates the
	requested modifications. A new Transaction_ID must be assigned by	requested modifications. A new Transaction_ID must be assigned by
	the client.	the client.


	skipping to change at line 2406 ¶	skipping to change at line 2405 ¶
	The client and the server must be mutually authenticated.	The client and the server must be mutually authenticated.
	Authenticated encryption must be used for data confidentiality and	Authenticated encryption must be used for data confidentiality and
	message integrity.	message integrity.

	The protocol does not provide security mechanisms to protect the	The protocol does not provide security mechanisms to protect the
	confidentiality and integrity of the packets transported between the	confidentiality and integrity of the packets transported between the
	client and the server. An underlying security protocol such as	client and the server. An underlying security protocol such as
	(e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport	(e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport
	Layer Security (TLS) [RFC8446]) must be used to protect the integrity	Layer Security (TLS) [RFC8446]) must be used to protect the integrity
	and confidentiality of protocol messages. In this case, if it is	and confidentiality of protocol messages. In this case, if it is

	possible to provide automated key management and associate each	possible to provide automated key management (Section 2.1 of
	transaction with a different key, inter-transaction replay attacks	[RFC4107]) and associate each transaction with a different key,
	can naturally be addressed. If the client and the server use a	inter-transaction replay attacks can naturally be addressed. If the
	single key, an additional mechanism should be provided to protect	client and the server use a single key, an additional mechanism
	against inter-transaction replay attacks between them. Clients must	should be provided to protect against inter-transaction replay
	implement DTLS record replay detection (Section 3.3 of [RFC6347]) or	attacks between them. Clients must implement DTLS record replay
	an equivalent mechanism to protect against replay attacks.	detection (Section 3.3 of [RFC6347]) or an equivalent mechanism to
		protect against replay attacks.

	DTLS and TLS with a cipher suite offering confidentiality protection	DTLS and TLS with a cipher suite offering confidentiality protection
	and the guidance given in [RFC7525] must be followed to avoid attacks	and the guidance given in [RFC7525] must be followed to avoid attacks
	on (D)TLS.	on (D)TLS.

	The client must silently discard CPNP responses received from unknown	The client must silently discard CPNP responses received from unknown
	CPNP servers. The use of a randomly generated Transaction-ID makes	CPNP servers. The use of a randomly generated Transaction-ID makes
	it hard to forge a response from a server with a spoofed IP address	it hard to forge a response from a server with a spoofed IP address
	belonging to a legitimate CPNP server. Furthermore, CPNP demands	belonging to a legitimate CPNP server. Furthermore, CPNP demands
	that messages from the server must include the correct identifiers of	that messages from the server must include the correct identifiers of

	skipping to change at line 2559 ¶	skipping to change at line 2559 ¶
	K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.	K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
	Smith, "COPS Usage for Policy Provisioning (COPS-PR)",	Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
	RFC 3084, DOI 10.17487/RFC3084, March 2001,	RFC 3084, DOI 10.17487/RFC3084, March 2001,
	<https://www.rfc-editor.org/info/rfc3084>.	<https://www.rfc-editor.org/info/rfc3084>.

	[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual	[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
	Private Network (VPN) Terminology", RFC 4026,	Private Network (VPN) Terminology", RFC 4026,
	DOI 10.17487/RFC4026, March 2005,	DOI 10.17487/RFC4026, March 2005,
	<https://www.rfc-editor.org/info/rfc4026>.	<https://www.rfc-editor.org/info/rfc4026>.


		[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
		Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
		June 2005, <https://www.rfc-editor.org/info/rfc4107>.

	[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,	[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
	and A. Gonguet, "Framework for Layer 3 Virtual Private	and A. Gonguet, "Framework for Layer 3 Virtual Private
	Networks (L3VPN) Operations and Management", RFC 4176,	Networks (L3VPN) Operations and Management", RFC 4176,
	DOI 10.17487/RFC4176, October 2005,	DOI 10.17487/RFC4176, October 2005,
	<https://www.rfc-editor.org/info/rfc4176>.	<https://www.rfc-editor.org/info/rfc4176>.

	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity	Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509	within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer	(PKIX) Certificates in the Context of Transport Layer

End of changes. 11 change blocks.
	17 lines changed or deleted	21 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/