PIM Working Group                                                  H. Li
Internet-Draft                                                   A. Wang
Intended status: Standards Track                           China Telecom
Expires: 17 November 2022                                      S. Venaas
                                                           Cisco Systems
                                                             16 May 2022


           IGMP/MLD Extension for Multicast Source Management
          draft-li-pim-igmp-mld-extension-source-management-03

Abstract

   This document describes extensions to Internet Group Management
   Protocol (IGMP) and Multicast Listener Discover (MLD) protocol for
   supporting interaction between multi cast sources and routers,
   accomplishing multi cast source management.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 17 November 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.



Li, et al.              Expires 17 November 2022                [Page 1]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Overview of Multicast Source Management . . . . . . . . . . .   3
     4.1.  Multicast Source Registration and Authorization . . . . .   4
     4.2.  Multicast Data Transmission and Termination . . . . . . .   4
     4.3.  Receiver Information Statistics . . . . . . . . . . . . .   5
   5.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Multicast Source Registration Message . . . . . . . . . .   5
     5.2.  Multicast Data Notification Message . . . . . . . . . . .   7
     5.3.  Multicast Receiver Statistics Message . . . . . . . . . .   8
   6.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Multicast Management for PCE as multicast controller  . .   9
   7.  Deployment Considerations . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  IGMP Type Numbers . . . . . . . . . . . . . . . . . . . .  11
     9.2.  ICMPv6 Parameters . . . . . . . . . . . . . . . . . . . .  11
   10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . .  11
   11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  11
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Among protocols for Internet Protocol (IP) multicast, there is no
   protocol specification for the source registration so far.  The
   current protocol focuses more on data control.  This document
   specifies some new messages to extend IGMPv3 [RFC3376] and MLDv2
   [RFC3810] for exchanging source registration information and data
   transmission control information between sources and routers.

   In addition, combined with the multi cast management process based on
   Soft Dedfined Network (SDN) architecture, such as that described in
   [I-D.li-pce-multicast], the transmission of multi cast source data
   can be effectively managed, enhancing the security and
   controllability of the multi cast service.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.




Li, et al.              Expires 17 November 2022                [Page 2]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


3.  Terminology

   The following terms are used in this document:

   *  BIER: Bit Index Explicit Replication

   *  ICMPv6: Internet Control Message Protocol version 6

   *  IGMP: Internet Group Management Protocol

   *  IP: Internet Protocol

   *  MDN: Multicast Data Notification

   *  MLD: Multicast Listener Discover

   *  MRS: Multicast Receiver Statistics

   *  MSR: Multicast Source Registration

   *  PCE: Path Computation Element

   *  RP: Rendezvous Point

   *  SDN: Software Defined Network

4.  Overview of Multicast Source Management

   Multicast source management includes multi cast source registration
   and authorization, multi cast data transmission and termination, and
   receiver information statistics.  Currently, multi cast source
   management is mainly used in Source Specific Multicast (SSM)
   scenario.  If multi cast source management is to be applied to Any-
   Source Multicast (ASM) scenarios, other mechanisms are needed.  ASM
   scenario is not discussed in this document.

   This document specifies IGMP and MLD protocol extensions for multi
   cast source management, including Multicast Source Registration (MSR)
   described in Section 5.1, Multicast Data Notification (MDN) described
   in Section 5.2 and Multicast Receiver Statistics (MRS) described in
   Section 5.3.










Li, et al.              Expires 17 November 2022                [Page 3]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


4.1.  Multicast Source Registration and Authorization

   Source systems send Multicast Source Registration messages to routers
   informing them that there are multi cast sources available to provide
   services.  The Multicast Source Registration message must contain the
   multi cast source address, service start time and validity period of
   the request.  In some scenarios, The Multicast Source Registration
   message also needs to contain credential for controlling multi cast
   source access.  Credential authentication can be performed on the
   first-hop router or on other systems.  The specific implementation
   can be adjusted according to the deployment.

   After receiving the registration message from the source system and
   authenticating, the routers send Multicast Source Registration
   messages with valid registration status response to the source
   systems and inform the source systems that the requests are approved.
   The routers will trigger a timer and maintain the registration status
   for the source systems until the timer expires.

   In contrast, the source systems can also send Multicast Source
   Registration messages to routers to withdraw the registration
   requests.  Then the routers will revoke the registration status and
   reply to the source systems.

   The source systems need periodically send registration messages to
   the routers to inform the router that the multi cast source is alive.
   Then routers will refresh the timer of the registration status.  If
   routers receive multi cast data from multi cast sources, they will
   refresh the timer.  During data delivery, the source systems does not
   have to send registration messages periodically.

   When the timer expires or the registration validity period expires,
   the router will release the registration status and send a Multicast
   Source Registration message with invalid registration status to the
   source system to inform it.

4.2.  Multicast Data Transmission and Termination

   Within the service validity of registration, when the first receiver
   joins a multi cast group with SSM address, the corresponding first
   hop router will send Multicast Data Notification message carrying
   multi cast group address to inform the source system that the source
   can send data to this multi cast group.








Li, et al.              Expires 17 November 2022                [Page 4]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


   For a specific (S, G) tuple, when the last receiver leaves the multi
   cast group, the first hop router will send Multicast Data
   Notification message carrying multi cast group address to inform the
   source system that the source should stop sending data to this multi
   cast group.

4.3.  Receiver Information Statistics

   For certain scenarios, a first hop router can learn receiver
   statistics for a specific (S, G) tuple.  For example, in SDN
   scenario, the receiver statistics of each egress router can be
   centrally managed by the controller.  The controller then aggregates
   these statistics and informs the first-hop router.

   In this case, if the first hop router has sent Multicast Data
   Notification message to the source system to inform the source system
   sending data, the first-hop router should periodically send Multicast
   Receiver Statistics messages to the source system synchronizing the
   receiver statistics.  In this way, the source system can perform
   analysis based on the receiver statistics, facilitating further
   optimization and scaling.

5.  Message Formats

   There are three types of IGMP and MLD messages associated with multi
   cast source advertisement described in this document.

5.1.  Multicast Source Registration Message

   MSR message is sent by multi cast source to request multi cast data
   transmission service activation or by router responding to the
   request from the multi cast source.

   MSR message has the following format:

















Li, et al.              Expires 17 November 2022                [Page 5]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = TBD1,2 |       |E|I|R|A|           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Credential Len        |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Multicast Source Address                   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Start Timestamp (64 bits)                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Duration (32 bits)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           Credential                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           Extension                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 1: MSR Message Format

   Type (8 bits): IGMP and MLD messages types, they need to be
   registered by the IANA.

   E(E-bit): E-bit set to 1 to indicate that extension is present in the
   message.  E-bit set to 0 to indicate that extension is not present in
   the message.  The E-bit MUST be set to 1 to indicate that the
   extension is present.  Otherwise, it MUST be 0.

   I (Identity flag, 1 bit): The I flag set to 1 indicates that the
   message is sent by multi cast source.  The I flag set to 0 indicates
   that the message is sent by router.

   R (Request flag, 1 bit): The R flag set to 1 indicates the request to
   activate transmission service.  The R flag set to 0 indicates
   revocation of the request.

   A (Authentication flag, 1 bit): The A flag set to 1 indicates success
   of request.  The A flag set to 0 indicates failure of request or
   revocation of the request.

   Checksum (16 bits): The Checksum is the 16-bit one's complement of
   the one's complement sum of the whole IGMP or MLD message (the entire
   IP payload).  For computing the checksum, the Checksum field is set
   to zero.  When receiving packets, the checksum MUST be verified
   before processing a message.






Li, et al.              Expires 17 November 2022                [Page 6]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


   Multicast Source Address (Variable length): contains IPv4 or IPv6
   address of the multi cast source requested.  If the MSR Message is
   used in IGMP, the length of the address is 32 bits.  If the MSR
   Message is used in MLD, the length of the address is 128 bits.

   Start Timestamp (8 bytes): indicates the start time when the multi
   cast source can provide data services.  Before this time, the multi
   cast source cannot send data to multi cast groups.

   Duration (1 byte): indicates the maximum duration that the multi cast
   source can provide data services in a valid registration request.

   Credential (Variable length): is used for authorization of multi cast
   sources.

   Extension: It is defined and described in
   [I-D.ietf-pim-igmp-mld-extension].It may contain a variable number of
   TLVs for flexible extension.

5.2.  Multicast Data Notification Message

   MDN message is sent by router to notify multi cast source to start or
   stop sending multi cast packets.  For different (S, G) tuples, the
   router needs to send multiple MDN messages.

   MDN message has the following format:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = TBD3,4 |  Reserved |E|C|           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Multicast Group Address                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           Extension                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 2: MDN Message Format

   Type (8 bits): IGMP and MLD messages types, they need to be
   registered by the IANA.

   E(E-bit): E-bit set to 1 to indicate that extension is present in the
   message.  E-bit set to 0 to indicate that extension is not present in
   the message.  The E-bit MUST be set to 1 to indicate that the
   extension is present.  Otherwise, it MUST be 0.






Li, et al.              Expires 17 November 2022                [Page 7]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


   C (Control flag, 1 bit): The C flag set to 1 indicates starting
   sending multi cast packets.  The C flag set to 0 indicates stopping
   sending multi cast packets.

   Checksum (16 bits): The Checksum is the 16-bit one's complement of
   the one's complement sum of the whole IGMP/MLD message (the entire IP
   payload).  For computing the checksum, the Checksum field is set to
   zero.  When receiving packets, the checksum MUST be verified before
   processing a message.

   Multicast Group Address (Variable length): contains IPv4 or IPv6
   address of the multi cast group requested.  If the MDN message is
   used in IGMP, the length of the address is 32 bits.  If the MDN
   message is used in MLD, the length of the address is 128 bits.

5.3.  Multicast Receiver Statistics Message

   MRS message is sent by router to multi cast source to synchronize
   receiver statistics of a group.  For different (S, G) tuples, the
   router needs to send multiple MRS messages.

   MRS message has the following format:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = TBD5,6 |   Reserved  |E|           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Multicast Group Address                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Number of Receivers                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           Extension                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 3: MRS Message Format

   Type (8 bits): IGMP and MLD messages types, they need to be
   registered by the IANA.

   E(E-bit): E-bit set to 1 to indicate that extension is present in the
   message.  E-bit set to 0 to indicate that extension is not present in
   the message.  The E-bit MUST be set to 1 to indicate that the
   extension is present.  Otherwise, it MUST be 0.








Li, et al.              Expires 17 November 2022                [Page 8]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


   Checksum (16 bits): The Checksum is the 16-bit one's complement of
   the one's complement sum of the whole IGMP/MLD message (the entire IP
   payload).  For computing the checksum, the Checksum field is set to
   zero.  When receiving packets, the checksum MUST be verified before
   processing a message.

   Multicast Group Address (Variable length): contains IPv4 or IPv6
   address of the multi cast group requested.  If the MRS message is
   used in IGMP, the length of the address is 32 bits.  If the MRS
   message is used in MLD, the length of the address is 128 bits.

   Number of Receivers (32 bits): indicates the number of receivers for
   a particular (S,G) tuple

6.  Use Case

6.1.  Multicast Management for PCE as multicast controller

   This section briefly describes procedures of multi cast source
   management through a simple example of Path Computation Element(PCE)
   based Bit Index Explicit Replication(BIER).

   The specific implementation process is as follows:

                           +------------------+
                   +-------+    Controller    +-------+
                   |       +--------^---------+       |
                   |                                  |
                   |                                  |
                S2 | S3/7       +--------+            |  S6
                   |    --------+   R3   +--------    |
                   |   /        +--------+        \   |
                   |  /                            \  |
  +------+  S1/9  +--+  S11  +--+          +--+     +--+  S5 +--------+
  |Source|--------|R1+-------+R5+----------+R6+-----+R7|-----|Receiver|
  +------+ S4/8/10+--+       +--+          +--+     +--+     +--------+
                   |                                  |
                   |         +--+          +--+       |
                   +---------+R2+----------+R4+-------+
                             +--+          +--+
   Figure 4: Topology of multi cast source management for PCE based BIER

   For the solution of PCE based BIER, the transmission of multi cast
   source registration and authorization and receiver information
   statistics depends on the PCRpt message and PCUpd message, defined in
   [RFC8231] and extended in [I-D.li-pce-multicast], between the router
   and the controller.




Li, et al.              Expires 17 November 2022                [Page 9]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


   S1, S4, S8 and S10 in the figure are multi cast source advertisement
   related processes.  S1 is the process by which multi cast sources
   send messages and data to router.  S4, S8 and S10 are the process by
   which router send messages to multi cast sources.  The other steps
   are beyond the scope of this document.

   Step 1(S1): Source sends IGMP or MLD MSR message to R1 requesting to
   activate the multi cast data transmission service.

   Step 2(S2): R1 sends multi cast information registration to
   controller via PCRpt message.

   Step 3(S3): The controller sends PCUpd message to the R1, carrying
   authentication result.

   Step 4(S4): R1 sends authentication result to the source via IGMP or
   MLD MSR message.  Source will conduct subsequent processing based on
   the authentication result, such as reapplying after the failure of
   authentication.

   Step 5(S5): Receivers send IGMP or MLD messages to R7 requesting to
   join or leave a multi cast group.

   Step 6(S6): R7 converts the IGMP or MLD messages of receivers into
   PCRpt message and send it to the controller.

   Step 7(S7): The controller sends PCUpd message to R1 to start or stop
   forwarding, carrying BitString.

   Step 8(S8): R1 sends IGMP or MLD MDN message to the source to notify
   the source sending multi cast packets to the specific multi cast
   group.

   Step 9(S9): Source sends multicast data to R1.

   Step 10(S10): R1 sends IGMP or MLD MSR messages with multi cast
   receivers' statistics to the source periodically.














Li, et al.              Expires 17 November 2022               [Page 10]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


7.  Deployment Considerations


8.  Security Considerations


9.  IANA Considerations


9.1.  IGMP Type Numbers

   IANA is requested to allocate a new code point within registry "IGMP
   Type Numbers" under "Internet Group Management Protocol (IGMP) Type
   Numbers" as follows:

    Type Number               Message Name
   -------------     -----------------------------
       TBD1           Multicast Source Activation
       TBD3           Multicast Data Notification
       TBD5          Multicast Receiver Statistics

9.2.  ICMPv6 Parameters

   IANA is requested to allocate a new code point within registry
   "ICMPv6 "type" Numbers" under "Internet Control Message Protocol
   version 6 (ICMPv6) Parameters" as follows:

    Type Number               Message Name
   -------------     -----------------------------
       TBD2           Multicast Source Activation
       TBD4           Multicast Data Notification
       TBD6          Multicast Receiver Statistics

10.  Contributor


11.  Acknowledgement


12.  Normative References











Li, et al.              Expires 17 November 2022               [Page 11]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


   [I-D.ietf-pim-igmp-mld-extension]
              Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda,
              "Internet Group Management Protocol version 3 (IGMPv3) and
              Multicast Listener Discovery version 2 (MLDv2) Message
              Extension", Work in Progress, Internet-Draft, draft-ietf-
              pim-igmp-mld-extension-07, 9 May 2022,
              <https://www.ietf.org/archive/id/draft-ietf-pim-igmp-mld-
              extension-07.txt>.

   [I-D.li-pce-multicast]
              Li, H., Wang, A., Zhang, Z., Chen, H., and R. Chen,
              "Multicast Tree Setup via PCEP", Work in Progress,
              Internet-Draft, draft-li-pce-multicast-01, 20 March 2022,
              <https://www.ietf.org/archive/id/draft-li-pce-multicast-
              01.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
              <https://www.rfc-editor.org/info/rfc3376>.

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,
              <https://www.rfc-editor.org/info/rfc3810>.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601,
              DOI 10.17487/RFC4601, August 2006,
              <https://www.rfc-editor.org/info/rfc4601>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.





Li, et al.              Expires 17 November 2022               [Page 12]


Internet-Draft   IGMP/MLD Extension for Multicast Source        May 2022


Authors' Addresses

   Huanan Li
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: lihn6@foxmail.com


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: wangaj3@chinatelecom.cn


   Stig Venaas
   Cisco Systems
   Tasman Drive
   San Jose, CA 95134
   United States of America
   Email: stig@cisco.com

























Li, et al.              Expires 17 November 2022               [Page 13]