



WIT Working Group                                                  Z. Li
Internet-Draft                                                     Z. Du
Intended status: Standards Track                            China Mobile
Expires: 5 January 2026                                         W. Cheng
                                                                 J. Wang
                                                                  Centec
                                                             4 July 2025


                   Dynamic Multicast Port Allocation
             draft-li-dynamic-multicast-port-allocation-00

Abstract

   This document proposes a dynamic multicast port allocation mechanism
   using Segment Routing over IPv6 (SRv6).  The solution enables
   decoupling between the destination port carried in multicast packets
   sent by the source and the actual receiving port used by receivers.
   This allows multicast receivers to dynamically allocate unused ports
   as receiving ports, eliminating the requirement for all receivers to
   use the same port number.  The mechanism defines a new SRv6 function
   End.MTP for automatic multicast port allocation and supports three
   operational modes to accommodate different deployment scenarios.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in .

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 5 January 2026.





Li, et al.               Expires 5 January 2026                 [Page 1]

Internet-Draft              WIT Working Group                  July 2025


Copyright Notice

   Copyright (c) 2025 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   In unicast TCP/IP communication flows, the same TCP connection or UDP
   "connection" uses identical source and destination IP addresses, with
   different port numbers distinguishing different services.  Examples
   include HTTP port 80, SSH port 22, Telnet port 23, SMTP port 25, and
   FTP port 21.

   IETF RFC 6335 [RFC6335] and RFC 7605 [RFC7605] categorize commonly
   used ports into three types:

   Well-Known Ports (0-1023): These are well-known port numbers that are
   permanently assigned to specific services.  The services mentioned
   above, such as HTTP and FTP, belong to this category.

   Registered Ports (1024-49151): These ports are not dynamically
   adjustable and do not have clearly defined services for specific
   objects.  Different programs can define their usage according to
   their own needs.

   Dynamic, Private or Ephemeral Ports (49152-65535): These port numbers
   cannot be registered and are used for private or customized services,
   as well as for dynamic port services.





Li, et al.               Expires 5 January 2026                 [Page 2]

Internet-Draft              WIT Working Group                  July 2025


   Port number resources are precious.  For unicast services, dynamic
   port allocation is commonly adopted.  However, for multicast
   services, dynamic allocation becomes challenging because it is
   difficult to confirm that specific port numbers are not occupied by
   other applications or services across all multicast receivers that
   need to join the multicast group.

2.  Problem Statement

   IPTV, real-time data transmission, and multimedia conferencing are
   typical application scenarios for multicast.  According to current
   multicast interaction procedures, multicast sources need to specify
   both the multicast IP address and multicast UDP port number when
   pushing multicast service flows.  For multicast services, using both
   multicast IP addresses and port numbers for service differentiation
   creates redundancy.  Taking IPTV as an example, different TV channels
   (services) typically use different multicast IP addresses, making
   port numbers less critical for service identification.

3.  Solution

   This document proposes a multicast port number allocation method that
   automatically assigns SID End.MTP sid to multicast packets carried by
   multicast sources or edge entry network nodes.  This decouples the
   destination port carried by the multicast source from the actual
   receiving port used by the recipient, allowing recipients to
   dynamically allocate unused ports as multicast receiving ports.  Each
   multicast recipient is not required to use the same receiving port
   number.

   3.1 End-to-End Mode

   In this mode, both the multicast source and multicast receiver
   servers on the end side must support SRv6 and the multicast port
   automatic SID allocation proposed by this scheme.  Additionally, the
   multicast receiver servers must maintain a mapping relationship
   between the destination port numbers carried in the multicast source
   packets and the dynamically allocated receiving port numbers (e.g.,
   multicast IP: 49155 ~ 50000).  Network devices do not require
   upgrades or modifications.

   3.2 Network-Only Mode









Li, et al.               Expires 5 January 2026                 [Page 3]

Internet-Draft              WIT Working Group                  July 2025


   In this mode, end-side multicast source and multicast receiver
   servers do not require upgrades (end-side compatibility mode).  The
   edge ingress network node near the multicast source, upon receiving
   multicast packets, inserts the proposed multicast port automatic
   allocation SID if the packet is an SRv6 packet, or performs IPv4 to
   IPv6 packet conversion if it is not an SRv6 packet.

   Intermediate network nodes forward multicast packets according to
   normal procedures.  Edge egress network nodes need to interact with
   their downstream multicast receivers in advance to obtain dynamically
   allocated receiving ports for the multicast IP service and construct
   port mapping tables.

   When receiving multicast packets carrying End.MTP SID, the egress
   node refreshes the port mapping table (to prevent aging), modifies
   the packet's destination receiving port to the dynamic port obtained
   from the table lookup (e.g., 49155 - 50000), then replicates
   multicast packets for other downstream receivers with table lookup
   and receiving port modification, and finally forwards to all
   downstream receivers.

   3.3 End-Network Collaboration Mode

   This mode is designed for multicast sources or multicast receiver
   servers that support SRv6 and the multicast port automatic SID
   allocation proposed in this scheme.  It can be further divided into
   two subtypes:

   1. the multicast source and edge exit network nodes collaborate to
   complete the interaction process and message parsing and processing
   actions of this scheme;

   2. the edge entry network nodes and multicast receivers collaborate
   to complete the interaction process and message parsing and
   processing actions of this scheme.

4.  Security Considerations

   TBD.

5.  IANA Considerations

   TBD.

Authors' Addresses






Li, et al.               Expires 5 January 2026                 [Page 4]

Internet-Draft              WIT Working Group                  July 2025


   Zhiqiang Li
   China Mobile
   Beijing
   100053
   China
   Email: lizhiqiangyjy@chinamobile.com


   Zongpeng Du
   China Mobile
   Beijing
   100053
   China
   Email: duzongpeng@chinamobile.com


   Wei Cheng
   Centec
   Suzhou
   215000
   China
   Email: chengw@centec.com


   Junjie Wang
   Centec
   Suzhou
   21500
   China
   Email: wangjj@centec.com





















Li, et al.               Expires 5 January 2026                 [Page 5]
