idnits 2.17.1 draft-tamplin-hybi-google-mux-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6455]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2012) is 4441 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HyBi Working Group J. Tamplin 3 Internet-Draft T. Yoshino 4 Intended status: Standards Track Google, Inc. 5 Expires: August 31, 2012 February 28, 2012 7 A Multiplexing Extension for WebSockets 8 draft-tamplin-hybi-google-mux-03 10 Abstract 12 The WebSocket Protocol [RFC6455] requires a new transport connection 13 for every WebSocket connection. This presents a scalability problem 14 when many clients connect to the same server, and is made worse by 15 having multiple clients running in different tabs of the same user 16 agent. This extension provides a way for separate logical WebSocket 17 connections to share an underlying transport connection. 19 Please send feedback to the hybi@ietf.org mailing list. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 31, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Physical and Logical Channel . . . . . . . . . . . . . . . 3 57 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 4 58 3. Interaction with other Extensions / Framing Mechanisms . . . . 5 59 3.1. Choosing the point to apply an extension . . . . . . . . . 6 60 4. Logical Channels . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Multiplex Control Frames . . . . . . . . . . . . . . . . . . . 11 64 7.1. Multiplex Control Opcodes . . . . . . . . . . . . . . . . 12 65 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 9. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 67 10. Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 11. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 12. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 70 13. Nesting . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 71 14. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 15. Close the Logical Channel . . . . . . . . . . . . . . . . . . 23 73 16. Fail the Logical Channel . . . . . . . . . . . . . . . . . . . 24 74 17. Fail the Physical Channel . . . . . . . . . . . . . . . . . . 25 75 18. Handling Operations On Logical Channel . . . . . . . . . . . . 26 76 19. Security Considerations . . . . . . . . . . . . . . . . . . . 27 77 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 78 21. Normative References . . . . . . . . . . . . . . . . . . . . . 29 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 81 1. Overview 83 This document describes a multiplexing extension for the WebSocket 84 Protocol. A client that supports this extension will advertise 85 support for it in the client's opening handshake using the 86 "Sec-WebSocket-Extensions" header. If the server supports this 87 extension and supports parameters compatible with the client's 88 request, it accepts the use of this extension by the 89 "Sec-WebSocket-Extensions" header in the server's opening handshake. 91 1.1. Physical and Logical Channel 93 Under this extension, one transport connection is shared by multiple 94 application-level instances. The WebSocket connection which lies 95 directly on the transport connection and negotiated this multiplexing 96 extension is called "physical channel". Virtually established 97 WebSocket connections for each WebSocket appplication instances are 98 called "logical channels". 100 Data for different logical channels are distinguished by the channel 101 ID allocated in the "Extension data" portion of each frame. 103 2. Conformance Requirements 105 All diagrams, examples, and notes in this specification are non- 106 normative, as are all sections explicitly marked non-normative. 107 Everything else in this specification is normative. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC2119. [RFC2119] 113 Requirements phrased in the imperative as part of algorithms (such as 114 "strip any leading space characters" or "return false and abort these 115 steps") are to be interpreted with the meaning of the key word 116 ("must", "should", "may", etc) used in introducing the algorithm. 118 Conformance requirements phrased as algorithms or specific steps MAY 119 be implemented in any manner, so long as the end result is 120 equivalent. (In particular, the algorithms defined in this 121 specification are intended to be easy to follow, and not intended to 122 be performant.) 124 3. Interaction with other Extensions / Framing Mechanisms 126 If WebSocket payload data is masked by a per-frame key, such masking 127 is applied to frames for each logical channel separately. 129 If any extension (e.g. compression) is placed before this extension 130 in the "Sec-WebSocket-Extensions" header of the physical channel, 131 that extension is applied to logical channels unless otherwise noted 132 in the extension's spec. 134 If such an extension define fields in the "Extension data", they come 135 after this multiplexing extension's field. 137 If any extension is placed after this extension in the 138 "Sec-WebSocket-Extensions" header of the physical channel, that 139 extension is applied to frames after multiplexing on the sender side, 140 and before demultiplexing on the receiver side unless otherwise noted 141 in the extension's spec. 143 If such an extension define fields in the "Extension data", they come 144 before this multiplexing extension's field. 146 A client MAY request such an extension for both the physical channel 147 and the logical channels by placing extension entries before and 148 after this multiplexing extension. In this case, the server SHOULD 149 reject at least either of them if it's useless to apply the same 150 extension twice. 152 For example, if we have a compression extension called foo-compress, 153 the client sends 155 Sec-WebSocket-Extensions: foo-compress, mux, foo-compress 157 in the client's opening handshake of the physical channel to request 158 use of the compression for both physical and logical channels. Then, 159 the server would send back 161 Sec-WebSocket-Extensions: mux, foo-compress 163 to apply compression after multiplexing, or 165 Sec-WebSocket-Extensions: foo-compress, mux 167 to apply compression to logical channels. 169 3.1. Choosing the point to apply an extension 171 Where to apply a compression extension makes difference to resource 172 consumption and flexibility. Compression algorithms often use some 173 memory to keep its context. Some of compression extensions may keep 174 using the same context for all the frames on the same connection. 176 If such an extension is applied to the physical channel, 177 intermediaries that want to demultiplex or multiplex the connection 178 need to decompress (before demultiplexing) and recompress (before 179 multiplexing again) all the frames. 181 If such an extension is applied to each logical channel, we can 182 control to which channel we apply the compression, so we can avoid 183 applying compression to channels transferring incompressible data. 184 Intermediaries that want to demultiplex can forward Application data 185 field leaving it untouched. However, compressing each logical 186 channel is expensive in terms of memory consumption. 188 4. Logical Channels 190 The multiplexing extension maintains separate logical channels, each 191 of which is fully the logical equivalent of an independent WebSocket 192 connection, including separate handshake headers. If the 193 multiplexing extension is successfully negotiated, the headers on the 194 opening handshake of the physical channel are automatically taken to 195 mean one for the logical channel 1, which is implicitly opened by 196 completing the handshake. New channels are added by the client 197 issuing the AddChannel request (note that only the client may 198 initiate new WebSocket connections), including any handshake headers 199 which do not have the same value as the client's opening handshake of 200 the physical channel. The server's AddChannel response likewise 201 includes any handshake headers which are different from the server's 202 opening handshake of the physical channel (the details of this are 203 TBD, but a simple suggestion for a delta encoding is given below). 204 Channel 0 (control channel) is reserved for multiplex control frames 205 and does not contain payload data from any logical channel. In 206 interpreting "Sec-WebSocket-Extensions" header for a logical channel, 207 the entry for this multiplexing extension is ignored but is used to 208 adjust parameters for the logical channel. A client which attempts 209 to add a channel to an existing connection that is not accepted by 210 the server SHOULD attempt to open a new WebSocket connection. 212 If any inconsistency is found between the "Sec-WebSocket-Extensions" 213 header for the physical channel and one for a logical channel (after 214 decoding header compression), the server MUST reject the AddChannel 215 request. 217 Once the multiplexing extension is negotiated on a connection, all 218 frames must be prefixed with a channel ID number in the "Extension 219 data". Control frames with a channel ID 0 refer to the physical 220 channel, other control frames MUST be delivered on the logical 221 channel in order with data frames for that logical channel. Control 222 frames SHOULD be sent only on channel 0 where possible, though 223 control frames for other extensions in particular may need to apply 224 to individual logical channels. 226 A receiver MUST _Fail the Physical Channel_ if any of these rules are 227 violated by the sender. 229 5. Flow Control 231 Each logical channel, including the implicitly created channel 1, is 232 initially given a quota of bytes that may be transmitted in each 233 direction without acknowledgement. It is illegal to send more bytes 234 than the remaining send quota, and the receiver MUST _Fail the 235 Logical Channel_ for any sender that does so. This send quota is 236 replenished via control frames as the receiver processes the data. 238 The initial send quota is specified with the "quota" extension 239 parameter, and defaults to 64k (TBD) if it is not specified. The 240 client and server each may specify a "quota" parameter and these are 241 unrelated -- each specifies how many bytes the other side may send 242 without acknowledgement. The quota values in the opening handshakes 243 of the physical channel apply to the implicitly opened channel 1. 245 6. Framing 247 If the extension is successfully negotiated during the opening 248 handshake, all frames have a channel ID in the "Extension data". The 249 channel ID is encoded as a variable number of bytes, as follows: 251 0 1 2 3 4 5 6 7 252 +-+-------------+ 253 |0|Channel ID(7)| 254 +-+-------------+ 256 0 1 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 258 +-+-+---------------------------+ 259 |1|0| Channel ID (14) | 260 +-+-+---------------------------+ 262 0 1 2 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 264 +-+-+-+-----------------------------------------+ 265 |1|1|0| Channel ID (21) | 266 +-+-+-+-----------------------------------------+ 268 0 1 2 3 269 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 270 +-+-+-+---------------------------------------------------------+ 271 |1|1|1| Channel ID (29) | 272 +-+-+-+---------------------------------------------------------+ 274 The base spec requires that a sequence of frames on the wire be a 275 sequence of valid fragments (or one of valid unfragmented frames). 276 The multiplexing extension relaxes this requirement to be for just 277 frames of one logical channel, and that frames of other logical 278 channels may be interleaved arbitrarily. 280 All frames with a non-zero channel ID must be delivered to the 281 specified logical channel in the order they are received, though 282 fragmentation may be changed if appropriate. Control frames with a 283 non-zero channel ID may also trigger additional processing by the 284 multiplexing extension. 286 Control frames with a channel ID of 0 refer to the physical 287 connection, and may also trigger additional processing - for example, 288 a close frame on the physical channel will close all logical channels 289 as well (details TBD). 291 If a frame doesn't contain valid channel ID, _Fail the Physical 292 Channel_. The cases where it's considered that the channel ID is 293 invalid are: 295 o The "Payload data" portion doesn't contain a complete channel ID. 297 o No channel has been opened for the channel ID. 299 o The channel has been closed and not reopened. 301 7. Multiplex Control Frames 303 Binary frames with a channel ID of 0 are multiplex control frames. 304 Unless another negotiated extension defines a meaning for them, any 305 data frames on channel 0 with an opcode other than "binary frame" 306 MUST _Fail the Physical Channel_ "Payload data" of a multiplex 307 control frames consists of a zero or more multiplex control blocks, 308 each defined as follows: 310 0 1 2 3 4 5 6 7 311 +---------------+ 312 | Objective | 313 + - - - - - - - + 314 : channel ID : 315 + - - - - - - - + 316 | (8-32) | 317 +-----+---------+ 318 | Opc | Opcdata | 319 +-----+---------+ 320 | Additional | 321 + - - - - - - - + 322 : data : 323 + - - - - - - - + 324 | | 325 +---------------+ 327 Objective channel ID 329 The channel ID of the logical channel objective to this operation. 330 Encoding is the same as that in the extension data (designated as 331 control channel) 333 opc 335 A multiplex control opcode as defined in Section 7.1. 337 opcdata 339 Data interpreted according to that opcode 341 Additional data 343 Zero or more bytes defined by that opcode 345 If any incomplete multiplex control block is found, _Fail the 346 Physical Channel_. 348 7.1. Multiplex Control Opcodes 350 0 - AddChannel request (only from client) 352 Create a new logical channel, exactly as if a new connection were 353 received on a separate transport connection, except for the 354 encoding of the headers. opcdata is interpreted as follows: 356 3 4 5 6 7 357 +-+---+---+ 358 |R|Enc|Len| 359 +-+---+---+ 361 R is reserved for future use. 363 Len is the number of bytes used to represent the length of 364 following handshake data minus 1. 366 Enc is an encoding scheme type: 368 0 - uncompressed 370 The handshake data that follow are uncompressed, and constitute 371 the complete set of a Request-Line and headers that would have 372 been sent on a WebSocket opening handshake 374 1 - delta-encoded 376 The handshake data that follow are delta-encoded, where any 377 header that is not given is assumed to have the same value as 378 that given on the client's opening handshake of the physical 379 connection. The only exceptions are the Request-Line and the 380 "Sec-WebSocket-Extensions" header. The Request-Line MUST be 381 sent even if it's the same as one in the client's opening 382 handshake for the physical channel. If the 383 "Sec-WebSocket-Extensions" header is not given, its value is 384 assumed to be the extension entry for this multiplexing 385 extension and ones following that in the client's opening 386 handshake of the physical channel. A header with an empty 387 value means that header is not inherited from the initial 388 connection. (TBD: this means that valueless headers cannot be 389 encoded with this scheme). 391 2-3 - reserved 393 Reserved for future use 395 The following n bytes, where n is the value of len inside opcdata 396 plus 1, are an 8-32 bit length of the client's opening handshake 397 for the new logical channel that follows, in network byte order. 398 It's encoded as defined by the enc value in opcdata. 400 The initial quota for the new logical channel is 0, so the client 401 may not send any data for this connection until the AddChannel 402 response is received. 404 The server always responds with an AddChannel response, described 405 below. 407 1 - AddChannel response (only from server) 409 opcdata is defined as follows: 411 3 4 5 6 7 412 +-----+---+ 413 |F|Enc|Len| 414 +-----+---+ 416 F is true if this response indicates a rejection of AddChannel 417 request. 419 Len is the number of bytes used to represent the length of 420 following handshake data minus 1. 422 Enc is an encoding scheme type defined as in the AddChannel 423 request (but replacing Request-Line with Response-Line). 425 If F is set, then the server has rejected the AddChannel request 426 and this SHOULD be treated exactly the same as if a separate 427 connection was attempted and the opening handshake failed. Enc is 428 ignored in this case, and the following n bytes, where n is the 429 value of len inside opcdata plus 1, are an 8-32 bit length of the 430 server's opening handshake for this logical channel that follows, 431 in network byte order. It SHOULD be treated as the response to an 432 HTTP Upgrade request for the request made by the AddChannel 433 request, For example: 435 HTTP/1.1 404 Not found 437 404 message body... 439 If F is not set, then the server has accepted the AddChannel 440 request. 442 The following n bytes, where n is the value of len inside opcdata 443 plus 1, are an 8-32 bit length of the server's opening handshake 444 for this logical channel that follows, in network byte order. 445 It's encoded according to enc as defined in the AddChannel 446 request, and the complete set of a Response-Line and headers after 447 decoding is treated exactly as if it was received in response to a 448 client's opening handshake on a separate connection. If the 449 server's opening handshake is validated, the client MUST take this 450 as _The WebSocket Connection is Established_. 452 2 - FlowControl 454 opcdata is defined as follows: 456 3 4 5 6 7 457 +-----+---+ 458 | RSV |Len| 459 +-----+---+ 461 RSV is reserved for future use. 463 Len is the number of bytes used to represent the number of bytes 464 to be added to the quota minus 1. 466 The following n bytes, treated as an unsigned integer in network 467 byte order, is added to the quota of the number of bytes the 468 receiver can have outstanding towards the sender of the 469 FlowControl message. (TBD: is it worth having some non-linear 470 encoding to reduce the average bits required to represent these 471 values?) 473 3 - DropChannel 475 DropChannel is used to close a logical channel for both error 476 cases and normal cases. 478 3 4 5 6 7 479 +-+---+---+ 480 |R|RSV|Len| 481 +-+---+---+ 483 If R is set, it means that this DropChannel control block was sent 484 due to _Fail the Logical Channel_. If R is unset, it means that 485 this DropChannel control block was sent due to _Close the Logical 486 Channel_. 488 RSV is reserved for future use. 490 Len is the number of bytes used to represent the length of 491 following reason data minus 1. 493 The following n bytes, where n is the value of len inside opcdata 494 plus 1, are an 8-32 bit length of the DropChannel reason string in 495 network byte order. 497 When an endpoint received DropChannel, the endpoint MUST remove 498 the logical channel and the application instance that used the 499 logical channel MUST treat this as closure of underlying 500 transport. 502 4-7 - reserved 504 Reserved for future use (TBD: do we need some support for 505 quiescence?) 507 8. Examples 509 _This section is non-normative._ 511 The examples below assume the handshake has already completed and the 512 x-google-mux extension was negotiated. 514 01 06 01 "Hello" 81 04 02 "bye" 80 07 01 " world" 516 This is a fragmented text message of "Hello world" on channel 1 517 interleaved with a text message of "bye" on channel 2. Note that 518 the sequence of opcodes/FIN bits cannot be understood without 519 considering the channel ID of each frame. 521 9. Client Behavior 523 When a client is asked to _Establish a WebSocket Connection_ by some 524 WebSocket application instance, it MAY choose to reuse an existing 525 WebSocket connection if all of the following are true: 527 o the multiplexing extension was successfully negotiated on that 528 connection 530 o the scheme portions of the URIs match exactly 532 o the host portions of the URIs either match exactly or resolve to 533 the same IP address (TBD: consider DNS rebind attacks) 535 o the port portions of the URIs (either explicit or implied by the 536 scheme) match exactly 538 o the connection has an availablle logical channel ID 540 If the client chooses to reuse an existing multiplexed connection, it 541 sends an AddChannel request as described above. If the AddChannel 542 request is accepted, WebSocket frames may be sent over that channel 543 as normal. If the server rejects the AddChannel, the client SHOULD 544 attempt to open a new physical WebSocket connection (for example, in 545 a shared hosting environment a server may not be prepared to 546 multiplex connections from different customers despite having a 547 single IP address for them). 549 10. Buffering 551 There will be lots of small frames sent in this protocol 552 (particularly replenishing send quotas), so a sender SHOULD attempt 553 to aggregate multiplex control blocks into larger WebSocket frames. 554 For data frames, a sender also SHOULD attempt to aggregate fragments 555 into one packet of the underlying transport. However, care must be 556 taken to avoid introducing excessive latency - the exact heuristics 557 for delaying in order to aggregate blocks is TBD. 559 11. Fairness 561 A multiplexing implementation MUST ensure reasonable fairness among 562 the logical channels. This is accomplished in several ways: 564 Receiver side 566 o The receiver MAY limit the other peer's send quota of a logical 567 channel by not replenishing the send quota to make sure that any 568 logical channel cannot dominate its buffer space on the sender. 570 o Send quota for one logical channel SHOULD be determined 571 considering the processing capacity (buffer size, processing 572 power, throughput, etc.) of that logical channel. For example, 573 when a logical channel with excess load cannot drain data from the 574 connection smoothly, the other logical channels get stuck even 575 when they have room of processing capacity. Unless there's 576 special need to give such a big quota for the channel, such 577 condition just makes overall performance low. 579 Sender side 581 o The sender MUST use a fair mechanism for selecting which logical 582 channel's data to send in the next WebSocket frame. Simple 583 implementations may choose a round-robin scheduler, while more 584 advanced implementations may adjust priority based on the amount 585 or frequency of data sent by each logical channel. 587 o The sender MUST fragment a message into smaller frames when it's 588 too big so that that logical channel will occupy the connection 589 and the other logical channels get stuck for long time. 591 o Logical channel frames that are sent SHOULD be limited in size 592 (such as by refragmenting) when there is contention for the 593 physical channel to minimize head-of-line blocking 595 12. Proxies 597 Proxies which do not multiplex/demultiplex are not affected by the 598 presence of this extension -- they simply process WebSocket frames as 599 usual. Proxies which filter or monitor WebSocket traffic will need 600 to understand the multiplexing extension in order to extract the data 601 from logical connections or to terminate individual logical 602 connections when policy is violated. Proxies which actively 603 multiplex connections or demultiplex them (for example, a mobile 604 network might have a proxy which aggregates WebSocket connections at 605 a single cell to conserve bandwidth to the main gateway) will require 606 additional configuration (perhaps including the client) that is 607 outside the scope of this document. 609 13. Nesting 611 TBD: Should we allow nesting of multiplexed channels, or should we 612 require that an intermediary multiplexing channels flatten it? The 613 advantage of nesting is it is conceptually cleaner and less work for 614 an intermediary, while the disadvantage is that flow control messages 615 will get amplified by nesting and the ultimate server's job is a bit 616 more complicated to keep a tree of channel mappings. 618 14. Timeout 620 When all the logical channels are closed, each endpoint MAY "Start 621 the WebSocket Closing Handshake" on the physical connection. Such 622 "Start the WebSocket Closing Handshake" operation SHOULD be delayed 623 assuming the physical channel may be reused after some idle period. 625 15. Close the Logical Channel 627 To _Close the Logical Channel_, an endpoint MUST send a DropChannel 628 multiplex control block with R bit unset. The endpoint MAY provide 629 the reason of closure in the DropChannel block. 631 16. Fail the Logical Channel 633 To _Fail the Logical Channel_, an endpoint MUST send a DropChannel 634 multiplex control block with R bit set. The endpoint MAY provide the 635 reason of failure in the DropChannel block. 637 17. Fail the Physical Channel 639 To _Fail the Physical Channel_, an endpoint MUST send a DropChannel 640 multiplex control block with objective channel ID of 0, and then 641 _Fail the WebSocket Connection_ on the physical channel with status 642 code of 1002 (TBD). 644 18. Handling Operations On Logical Channel 646 When an endpoint is asked to perform any operation defined in the 647 WebSocket Protocol except for _Close the WebSocket Connection_ by 648 some application instance, it MUST perform it on the corresponding 649 logical channel. 651 Any event on a logical channel except for _The WebSocket Connection 652 is Closed_, MUST be taken as one for the corresponding application 653 instance. 655 When an endpoint is asked to do _Close the WebSocket Connection_ by 656 some application instance, it MUST perform _Close the Logical 657 Channel_ on the corresponding logical channel. 659 When a DropChannel is received and the logical channel hasn't yet 660 received DropChannel before that, it MUST be taken as _The WebSocket 661 Connection is Closed_ event for the corresponding application 662 instance. 664 19. Security Considerations 666 To protect a server from denial-of-service attack, implementation 667 SHOULD have a way to limit the number of concurrent logical channels. 669 TBD 671 20. IANA Considerations 673 This specification is registering a value of the Sec-WebSocket- 674 Extension header field in accordance with Section 11.4 of the 675 WebSocket protocol [RFC6455] as follows: 677 Extension Identifier 679 mux 681 Extension Common Name 683 Mulplexing Extension for WebSockets 685 Extension Definition 687 This document [draft-tamplin-hybi-google-mux] defines the mux 688 extension. 690 Known Incompatible Extensions 692 None 694 21. Normative References 696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 697 Requirement Levels", BCP 14, RFC 2119, March 1997. 699 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 700 RFC 6455, December 2011. 702 Authors' Addresses 704 John A. Tamplin 705 Google, Inc. 707 Email: jat@google.com 709 Takeshi Yoshino 710 Google, Inc. 712 Email: tyoshino@google.com