< draft-zeng-turn-cluster-02.txt		draft-zeng-turn-cluster-03.txt >
	tram W. Zeng		tram W. Zeng
	Internet-Draft Ant Group		Internet-Draft Ant Group
	Intended status: Informational 13 November 2021		Intended status: Informational 9 May 2022
	Expires: 17 May 2022		Expires: 10 November 2022
	TURN Cluster: Scale out TURN cluster by routable transaction id		TURN Cluster: Scale out TURN cluster by routable transaction id
	draft-zeng-turn-cluster-02		draft-zeng-turn-cluster-03
	Abstract		Abstract
	The TURN protocol is designed to solve the connectivity problem of		The TURN protocol is designed to solve the connectivity problem of
	Peer-to-Peer Communication when NAT devices exist, by allowing each		Peer-to-Peer Communication when NAT devices exist, by allowing each
	peer to establish a data channel on TURN servers. Since there are		peer to establish a data channel on TURN servers. Since there are
	some specific requirements in the use of TURN, such as RTP/RTCP		some specific requirements in the use of TURN, such as RTP/RTCP
	connection pairs must be sent to the same TURN server, it is not easy		connection pairs must be sent to the same TURN server, it is not easy
	to scale a single TURN server into a TURN cluster. In addition, a		to scale a single TURN server into a TURN cluster. In addition, a
	TURN service cluster also needs to consider how to achieve good load		TURN service cluster also needs to consider how to achieve good load
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 17 May 2022.		This Internet-Draft will expire on 10 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Overview of an TURN ICE process . . . . . . . . . . . . . . . 5		2. Overview of an TURN ICE process . . . . . . . . . . . . . . . 5
	3. Architectural and Interactive Process . . . . . . . . . . . . 9		3. Architectural and Interactive Process . . . . . . . . . . . . 9
	3.1. Overview of the Architectural . . . . . . . . . . . . . . 9		3.1. Overview of the Architectural . . . . . . . . . . . . . . 9
	3.2. Overview of interaction process . . . . . . . . . . . . . 11		3.2. Overview of interaction process . . . . . . . . . . . . . 11
	skipping to change at page 22, line 38 ¶		skipping to change at page 22, line 38 ¶
	IANA is requested to assign the type values for the attribute		IANA is requested to assign the type values for the attribute
	ENCRYPTED-RELAYED-ADDRESS(defined in Section 4.1) and ENCRYPTED-PEER-		ENCRYPTED-RELAYED-ADDRESS(defined in Section 4.1) and ENCRYPTED-PEER-
	ADDRESS(defined in Section 4.4).		ADDRESS(defined in Section 4.4).
	+----------------+---------------------------+-----------------+		+----------------+---------------------------+-----------------+
	| attribute type | description | reference |		| attribute type | description | reference |
	+----------------+---------------------------+-----------------+		+----------------+---------------------------+-----------------+
	| | value for | |		| | value for | |
	| TBD1 | ENCRYPTED-RELAYED-ADDRESS,| this RFC |		| TBD1 | ENCRYPTED-RELAYED-ADDRESS,| this RFC |
	| | used to carry relayed | ({{ERA-gen}})) |		| | used to carry relayed | |
	| | address safely | |		| | address safely | |
	+----------------+---------------------------+-----------------+		+----------------+---------------------------+-----------------+
	| | value for | |		| | value for | |
	| TBD2 | ENCRYPTED-PEER-ADDRESS, | this RFC |		| TBD2 | ENCRYPTED-PEER-ADDRESS, | this RFC |
	| | used to carry peer address| ({{EPA_gen}}) |		| | used to carry peer address| |
	| | safely | |		| | safely | |
	+----------------+--------------===----------+-----------------+		+----------------+--------------===----------+-----------------+
	IANA is requested to assign the err code for the TBD3(defined in		IANA is requested to assign the err code for the TBD3(defined in
	Section 4.3) and TBD4(defined in Section 4.4) depicted below:		Section 4.3) and TBD4(defined in Section 4.4) depicted below:
	+----------+------------------------+-----------------+		+----------+------------------------+-----------------+
	| err code | description | reference |		| err code | description | reference |
	+----------+------------------------+-----------------+		+----------+------------------------+-----------------+
	| | request failed due to | |		| | request failed due to | |
End of changes. 7 change blocks.
	10 lines changed or deleted		10 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/