rfc3843.RObust Header Compression (ROHC) A Compression Profile for IP

The Dell EMC S5048-ON switch is an innovative, future-ready T op-of-Rack (T oR) open networking switch providing excellent capabilities and cost-effectiveness for the enterprise, mid-market, Tier2 cloud and NFV service providers with demanding compute and storage traffic environments.The S5048F-ON 25GbE switch is Dell’s latest disaggregated hardware and software data center networking solution that provides backward compatible 25GbE server port connections, 100GbE uplinks, storage optimized architecture, and a broad range of functionality to meet the growing demands of today’s data center environment now and in the future.The compact S5048F-ON model design provides industry-leading density with up to 72 ports of 25GbE or up to 48 ports of 25GbE and 6 ports of 100GbE in a 1RU form factor.Using industry-leading hardware and a choice of Dell’s OS9 or select 3rd party network operating systems and tools, the S5048F-ON delivers non-blocking performance* for workloads sensitive to packet loss. The compact S5048F-ON model provides multi rate speed enabling denser footprints and simplifying migration to 25GbE server connections and 100GbE fabrics. Priority-based flow control (PFC), data center bridge exchange (DCBX) and enhanced transmission selection (ETS) make the S5048F-ON an excellent choice for DCB environments.Maximum performance and functionalityThe Dell EMC Networking S-Series S5048F-ON is a high-performance, multi-function, 10/25/40/50/100 GbE T oR switch purpose-built for applications in high-performance data center, cloud and computing environments.In addition, the S5048F-ON incorporates multiple architectural features that optimize data center network flexibility, efficiency, and availability, including IO panel to PSU airflow or PSU to IO panel airflow for hot/cold aisle environments, and redundant, hot-swappable power supplies and fans. Key applications• Organizations looking to enter the software-defined data center era with a choice of networking technologies designed to deliver theflexibility they need• Native high-density 25 GbE T oR server access in high-performance data center environments• 25 GbE backward compatible to 10G and 1G for future proofing and data center server migration to faster uplink speeds.• Capability to support mixed 25G and 10G servers on front panel ports • iSCSI storage deployment including DCB converged lossless transactions • Suitable as a T oR or Leaf switch in 100G Active Fabric implementations • As a high speed VXLAN L2 gateway that connects the hypervisor-based overlay networks with non-virtualized infrastructure• Emerging applications requiring hardware support for new protocols Key features• 1RU high-density 25/10/1 GbE T oR switch with up to forty eight ports of native 25 GbE (SFP28) ports supporting 25 GbE without breakout cables• Multi-rate 100GbE ports support 10/25/40/50/100 GbE• 3.6 Tbps (full-duplex) non-blocking, store and forward switching fabric delivers line-rate performance under full load*• Scalable L2 and L3 Ethernet switching with QoS and a full comple-ment of standards-based IPv4 and IPv6 features, including OSPF and BGP routing support• L2 multipath support via Virtual Link Trunking (VLT) and multiple VLT (mVLT) multi-chassis link aggregation technology• VRF-lite enables sharing of networking infrastructure and provides L3 traffic isolation across tenants• Open Automation Framework adding automated configuration and provisioning capabilities to simplify the management of networkenvironments• Jumbo frame support for large data transfers• 128 link aggregation groups with up to eight members per group, using enhanced hashing• Redundant, hot-swappable power supplies and fans• I/O panel to power supply airflow or power supply to I/O panel airflow • T ool-less enterprise ReadyRails™ mounting kits reducing time and resources for switch rack installation• Power-efficient operation up to 45°C helping reduce cooling costs in temperature-constrained deployments (Dell EMC Fresh Air 2.0compliant)• Converged network support for DCB and ECN capability• Supports the open source Open Network Install Environment (ONIE) for zero touch installation of alternate network operating systems• Fibre Channel, FCoE, FCoE transit (FIP Snooping) and NPIV ProxyDELL EMC NETWORKING S5048F-ONHigh-performance open networking top-of-rack switch with native 25G server ports and 100G network fabric connectivity**future deliverable48 line-rate 25 Gigabit Ethernet SFP28 ports6 line-rate 100 Gigabit Ethernet QSFP28 ports1 RJ45 console/management port with RS232signaling1 Micro-USB type B optional console port1 10/100/1000 Base-T Ethernet port used asmanagement port1 USB type A port for the external mass storage Size: 1 RU, 1.72 h x 17.1 w x 18” d(4.4 h x 43.4 w x 45.7 cm d)Weight: 22lbs (9.98kg)ISO 7779 A-weighted sound pressure level: 59.6 dBA at 73.4°F (23°C)Power supply: 100–240 VAC 50/60 HzMax. thermal output: 1956 BTU/hMax. current draw per system:5.73A/4.8A at 100/120V AC2.87A/2.4A at 200/240V ACMax. power consumption: 573 Watts (AC)T yp. power consumption: 288 Watts (AC) with all optics loadedMax. operating specifications:Operating temperature: 32° to 113°F (0° to 45°C) Operating humidity: 10 to 90% (RH), non-condensingFresh Air Compliant to 45°CMax. non-operating specifications:Storage temperature: –40° to 158°F (–40° to70°C)Storage humidity: 5 to 95% (RH), non-condensing RedundancyT wo hot swappable redundant power suppliesHot swappable redundant fansPerformanceSwitch fabric capacity: 3.6TbpsForwarding capacity: Up to 2,678 MppsPacket buffer memory: 22MB (16MB supported in initial release)CPU memory: 8GBMAC addresses: 132K (in scaled-l2-switch mode) ARP table: 82K (in scaled-l3-hosts mode)IPv4 routes: Up to 128KIPv6 routes: Up to 64K (20k currently supported) Multicast hosts: Up to 8KLink aggregation: 128 groups, 32 members per LAG groupLayer 2 VLANs: 4KMSTP: 64 instancesLAG Load Balancing: Based on layer 2, IPv4 or IPv6 header, or tunnel inner header contentsQoS data queues: 8QoS control queues: 12QoS: 1024 entries per TileIngress ACL: 1024 entries per TileEgress ACL: 1k entries per TilePre-Ingress ACL: 1k entries per TileIEEE Compliance802.1AB LLDP802.1D Bridging, STP802.1p L2 Prioritization802.1Q VLAN T agging, Double VLAN T agging,GVRP802.1Qbb PFC802.1Qaz ETS802.1s MSTP802.1w RSTP802.1X Network Access Control802.3ab Gigabit Ethernet (1000BASE-T) orbreakout802.3ac Frame Extensions for VLAN T agging 802.3ad Link Aggregation with LACP 802.3ba 40 Gigabit Ethernet (40GBase-SR4,40GBase-CR4, 40GBase-LR4, 100GBase-SR10, 100GBase-LR4, 100GBase-ER4) onoptical ports802.3bj 100 Gigabit Ethernet802.3u Fast Ethernet (100Base-TX) on mgmtports802.3x Flow Control802.3z Gigabit Ethernet (1000Base-X) with QSAANSI/TIA-1057 LLDP-MEDForce10 PVST+Jumbo MTU support 9,416 bytesLayer2 Protocols4301 Security Architecture for IPSec*4302 IPSec Authentication Header*4303 ESP Protocol*802.1D Compatible802.1p L2 Prioritization802.1Q VLAN T agging802.1s MSTP802.1w RSTP802.1t RPVST+802.3ad Link Aggregation with LACPVL T Virtual Link T runkingRFC Compliance768 UDP793 TCP854 T elnet959 FTP1321 MD51350 TFTP2474 Differentiated Services2698 T wo Rate Three Color Marker3164 Syslog4254 S SHv2General IPv4 Protocols791 I Pv4792 ICMP826 ARP1027 Proxy ARP1035 DNS (client)1042 Ethernet Transmission1191 Path MTU Discovery1305 NTPv41519 CIDR1542 BOOTP (relay)1858 IP Fragment Filtering2131 DHCP (server and relay)5798 V RRP3021 31-bit Prefixes3046 D HCP Option 82 (Relay)1812 Requirements for IPv4 Routers1918 Address Allocation for Private Internets2474 Diffserv Field in IPv4 and Ipv6 Headers2596 A ssured Forwarding PHB Group3195 Reliable Delivery for Syslog3246 E xpedited Assured Forwarding4364 V RF-lite (IPv4 VRF with OSPF and BGP)*General IPv6 Protocols1981 Path MTU Discovery*2460 I Pv62461 Neighbor Discovery*2462 S tateless Address AutoConfig2463 I CMPv62675 Jumbo grams3587 Global Unicast Address Format4291 IPv6 Addressing2464 T ransmission of IPv6 Packets over EthernetNetworks2711 IPv6 Router Alert Option4007 I Pv6 Scoped Address Architectureand Routers4291 IPv6 Addressing Architecture4861 Neighbor Discovery for IPv64862 I Pv6 Stateless Address Autoconfiguration5095 Deprecation of T ype 0 Routing Headers in IPv6IPv6 Management support (telnet, FTP, TACACS,RADI US, SSH, NTP)RIP1058 RIPv12453 R I Pv2OSPF (v2/v3)1587 NSSA (not supported in OSPFv3)1745 OSPF/BGP interaction1765 OSPF Database overflow2154 MD52328 OSPFv22370 Opaque LSA3101 OSPF NSSA3623 O SPF Graceful Restart (Helper mode)*BGP1997 Communities2385 M D52439 R oute Flap Damping2545 B GP-4 Multiprotocol Extensions for IPv6I nter-Domain Routing2796 Route Reflection2842 C apabilities2858 M ultiprotocol Extensions2918 Route Refresh3065 C onfederations4271 BGP-44360 E xtended Communities4893 4-byte ASN5396 4-byte ASN Representation5492 C apabilities AdvertisementMulticast1112 IGMPv12236 I GMPv23376 IGMPv3MSDPPIM-SMPIM-SSMNetwork Management1155 SMIv11157 SNMPv11212 Concise MIB Definitions1215 SNMP Traps1493 Bridges MIB1850 OSPFv2 MIB1901 Community-Based SNMPv22011 IP MIB2096 I P Forwarding T able MIB2578 SMI v22579 T extual Conventions for SMIv22580 C onformance Statements for SMIv22618 RADIUS Authentication MIB2665 E thernet-Like Interfaces MIB2674 Extended Bridge MIB2787 VRRP MIB2819 RMON MIB (groups 1, 2, 3, 9)2863 I nterfaces MIB3273 RMON High Capacity MIB3410 SNMPv33411 SNMPv3 Management Framework3412 Message Processing and Dispatching for theSimple Network Management Protocol (SNMP)3413 SNMP Applications3414 User-based Security Model (USM) forSNMPv33415 VACM for SNMP3416 SNMPv23417 Transport mappings for SNMP3418 SNMP MIB3434 R MON High Capacity Alarm MIB3584 C oexistance between SNMP v1, v2 and v3 4022 I P MIB4087 IP Tunnel MIB4113 UDP MIB4133 Entity MIB4292 M IB for IP4293 M IB for IPv6 T extual Conventions4502 R MONv2 (groups 1,2,3,9)5060 PIM MIBANSI/TIA-1057 LLDP-MED MIBDell_ITA.Rev_1_1 MIBdraft-ietf-idr-bgp4-mib-06 BGP MIBv1IEEE 802.1AB LLDP MIBIEEE 802.1AB LLDP DOT1 MIBIEEE 802.1AB LLDP DOT3 MIB sFlowv5 sFlowv5 MIB (version 1.3)DELL-NETWORKING-BGP4-V2-MIB(draft-ietf-idr-bgp4-mibv2-05)DELL-NETWORKING-IF-EXTENSION-MIBDELL-NETWORKING-LINK-AGGREGATION-MIB DELL-NETWORKING-COPY-CONFIG-MIBDELL-NETWORKING-PRODUCTS-MIBDELL-NETWORKING-CHASSIS-MIBDELL-NETWORKING-SMIDELL-NETWORKING-TCDELL-NETWORKING-TRAP-EVENT-MIBDELL-NETWORKING-SYSTEM-COMPONENT-MIB DELL-NETWORKING-FIB-MIBDELL-NETWORKING-FPSTATS-MIBDELL-NETWORKING-ISIS-MIBDELL-NETWORKING-FIPSNOOPING-MIBDELL-NETWORKING-VIRTUAL-LINK-TRUNK-MIB DELL-NETWORKING-DCB-MIBDELL-NETWORKING-OPENFLOW-MIBDELL-NETWORKING-BMP-MIBDELL-NETWORKING-BPSTATS-MIBSecuritydraft-grant-tacacs-02 TACACS+2404 The Use of HMACSHA-1-96 within ESP and AH 2865 R ADI US3162 Radius and IPv63579 RADIUS support for EAP3580 802.1X with RADIUS3768 EAP3826 A ES Cipher Algorithm in the SNMP User Base Security Model4250, 4251, 4252, 4253, 4254 SSHv24301 Security Architecture for IPSec4302 I PSec Authentication Header4807 IPsecv Security Policy DB MIBData center bridging802.1Qbb Priority-Based Flow Control802.1Qaz Enhanced Transmission Selection (ETS)* Data Center Bridging eXchange (DCBx)DCBx Application TLV (iSCSI, FCoE*) Regulatory complianceSafetyUL/CSA 60950-1, Second EditionEN 60950-1, Second EditionIEC 60950-1, Second Edition Including All National Deviations and Group DifferencesEN 60825-1 Safety of Laser Products Part 1: Equipment Classification Requirements and User’s GuideEN 60825-2 Safety of Laser Products Part 2: Safety of Optical Fibre Communication SystemsIEC 62368-1FDA Regulation 21 CFR 1040.10 and 1040.11 Emissions & ImmunityFCC Part 15 (CFR 47) (USA) Class AICES-003 (Canada) Class AEN55032: 2015 (Europe) Class ACISPR32 (International) Class AAS/NZS CISPR32 (Australia and New Zealand) Class AVCCI (Japan) Class AKN32 (Korea) Class ACNS13438 (T aiwan) Class ACISPR22EN55022EN61000-3-2EN61000-3-3EN61000-6-1EN300 386EN 61000-4-2 ESDEN 61000-4-3 Radiated ImmunityEN 61000-4-4 EFTEN 61000-4-5 SurgeEN 61000-4-6 Low Frequency Conducted Immunity NEBSGR-63-CoreGR-1089-CoreATT-TP-76200VZ.TPR.9305RoHSRoHS 6 and China RoHS compliantCertificationsJapan: VCCI V3/2009 Class AUSA: FCC CFR 47 Part 15, Subpart B:2009, Class A Warranty1 Year Return to DepotLearn more at /NetworkingIT Lifecycle Servicesfor NetworkingExperts, insights and easeOur highly trained experts, withinnovative tools and proven processes,help you transform your IT investments into strategic advantages.Plan & DesignLet us analyze yourmultivendor environmentand deliver a comprehensivereport and action plan to buildupon the existing network andimprove performance.Deploy & IntegrateGet new wired or wirelessnetwork technology installedand configured with ProDeploy.Reduce costs, save time, andget up and running fast.EducateEnsure your staff builds theright skills for long-termsuccess. Get certified on DellEMC Networking technologyand learn how to increaseperformance and optimizeinfrastructure.Manage & SupportGain access to technical expertsand quickly resolve multivendornetworking challenges withProSupport. Spend less timeresolving network issues andmore time innovating.OptimizeMaximize performance fordynamic IT environments withDell EMC Optimize. Benefitfrom in-depth predictiveanalysis, remote monitoringand a dedicated systemsanalyst for your network.RetireWe can help you resell or retireexcess hardware while meetinglocal regulatory guidelines andacting in an environmentallyresponsible way.Learn more at/lifecycleservices*Future release**Packet sizes over 147 Bytes。

RObust Header Compression (ROHC):A Profile for TCP/IP (ROHC-TCP)摘要本文档为TCP/IP报头指定了一个健壮的头压缩机制。

该机制被称为ROHC-TCP，提供了有效且健壮的TCP头压缩，包括频繁使用的TCP选项，如SACK（选择性确认）和时戳。

ROHC-TCP在错误率高和RTT长的链路上表现良好，常有许多这样的链路带宽有限，必需要头压缩。

目录1. 介绍2. 术语基础上下文基础上下文是压缩器和解压器都已经证实的上下文。

一个基础上下文可以被用来作为使用复制建立新上下文的参考基础上下文标识符（基础CID）基础CID是标识基础上下文的CID，从基础上下文中可以提取到上下文复制时需要的信息基础报头未压缩报文的最里层的IP和TCP报头的压缩形式链接条目一条链基于相似的特性组合条目。

ROHC-TCP为静态、动态、可复制或不规则的条目定义条目链。

链接是通过为每个报头添加条目来完成的，例如以条目在未压缩报文中出现顺序来添加给链。

上下文复制(CR)上下文复制是一种基于另外一个存在的有效上下文（一个基础上下文）来建立和初始化一个新上下文的机制。

引入这个机制是为了减少上下文建立流程的负载，特别适用于压缩多个短暂TCP连接，这些连接可能同时或近乎同时发生ROHC-TCP报文类型ROHC-TCP使用3种报文类型：初始和刷新（IR）报文类型，上下文修复（IR-CR）报文类型和压缩（CO）报文类型短暂（Short-lived） TCP传输是指用每个单个连接只传输少量报文的TCP连接2.1缩写2.2翻译术语Profile 机制Packet报文Header 报头、头Fields字段、域formal notation标注格式3. 背景3.1现存TCP/IP头压缩机制3.2TCP/IP头字段分类报文有可能压缩正是由于报文（尤其是连续的报文）的头字段之间有很大的冗余。

对于TCP/IP 头压缩要利用这些特性，了解各种头部字段的变化模式就很重要。

The ILM Performance Level ‘d’/SIL2 series of Gefran are pressure transmitters for using in high temperature environment with IO-Link output.The main characteristic of this series is the capability to read temperature of the media up to 400°C (750°F).The constructive principle is based on the hydraulic trasmission of the pressure.The fluid-filled system assures the temperature stability.This “Smart” transmitter with IO-Link output is ready for “Industry 4.0” requirements.“ILM” is Gefran’s exclusive series of high-temperature pressure sensors with filling fluid and digital output.This new series ILM with “IO-Link ”interface is a Smart device specifically designed to meet the requirements of “Industry 4.0” environment, with auxiliary information suitable to prevent machine downtime and thanks to the filling fluid solution it can withstand up to 400°C of process temperature.In addition, with PLd and SIL2 approvals, the ILM series is the best solution for “functional safety” applications.MAIN FEATURES• Pressure ranges from:0-17 to 0-2000 bar / 0-250 to 0-30000 psi • Accuracy: < ±0.25% FS (H); < ±0.5% FS (M)• 1/2-20UNF, M18x1.5 standard threads; other types available on request • 15-5 PH diaphragm with GTP+ coating fother typesavailable on request• 17-7 PH corrugated diaphragm with GTP+ coating forranges below 100bar-1500psi.• Stem material: 17-4 PH• IO-Link output, ready for “Industry 4.0”• Rangeabilty: 3:1• PLd and SIL2 approvals for Functional safety • Autozero function • Auxiliary information over IO-Link protocol GTP+ (advanced protection)Coating with high resistance against corrosion, abrasion and high temperatureAUTOZERO FUNCTIONAll signal variations in the absence of pressure can be eliminated by using the Autozero function.This Autozero function is activated via IO-Link command.The procedure is allowed only at zero pressure.TECHNICAL SPECIFICATIONSMELT PRESSURE TRANSMITTERS ILM SERIES IO-LINK VERSIONAccuracy (1)H <±0.25% FS (100...2000 bar) M <±0.5% FS (17...2000 bar)Measurement range0..17 to 0..2000bar 0..250 to 0..30000psiMaximum overpressure(without degrading performances)2 x FS1.5 x FS above 700bar/10000p si Measurement principle Extensimetric (Thick film)Power supply18-30 VdcMaximum current absorption (*) 1 W(1.2 W with relay optional)Zero offset <±0.25% FSZero adjustment“Autozero” functionCommunication interfaceIO-Link Cycle time2 msec IO-Link version 1.1 Transmission type COM2 (38.4 kBaud)Profile Smart sensor generic profileSIO ModeYes Required class for Master port A Pressure process data resolution 14 bit Analog output resolution 16 bitTemperature process data resolution16 bitRangeability3:1 (analogue output opt.)Calibration signal80% FS Power supply polarity reverse protection YES Compensed temperature range housing 0...+85°C Operating temperature range housing -30...+85°C Storage temperature range housing -40...+125°C Thermal drift in compesated range: Zero / Calibration / Sensibility < 0.02% FS/°C Diaphragm maximum temperature400°C / 750°FZero drift due to change in process temperature (zero)< 2 bar/100°C /< 15 psi/100°F Integral temperature (optional) Accuracy T/C type JProtection degree(5-pole female connector)IP65with suitable mating connectorFS = Full scale output: (1) BFSL method (Best Fit Straight Line): includes com -bined effects of Non-Linearity, Hysteresis and Repeatability (according to IEC 62828-2).(*) does not take into account absorption on DO in SIO mode (limited to 200mA)。

Callon Page i Use of OSI IS-IS for Routing in TCP/IP and DualEnvironmentsStatus of this MemoThis RFC specifies a protocol on the IAB Standards Track for the internet community, and re-quests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distri-bution of this memo is unlimited.AbstractThis RFC specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force.The OSI IS-IS protocol has reached a mature state, and is ready for implementation and opera-tional use. The most recent version of the OSI IS-IS protocol is contained in ISO DP 10589 [1].The proposed standard for using IS-IS for dual routing will therefore make use of this version (with a minor bug correction, as discussed in Annex B). We expect that future versions of this proposed standard will upgrade to the final International Standard version of IS-IS when avail-able.Comments should be sent to “isis@”.Contents1Introduction: Overview of the Protocol (1)1.1What the Integrated IS−IS offers .......................................................................................................11.2Overview of the ISO IS−IS Protocol .................................................................................................21.3Overview of the Integrated IS−IS ......................................................................................................51.4Support of Mixed Routing Domains..................................................................................................7Ross W. Callon Digital Equipment CorporationDecember, 1990Network Working GroupRequest for Comments: 11951.5Advantages of Using Integrated IS−IS (7)2Symbols and Abbreviations (9)3Subnetwork Independent Functions (10)3.1Exchange of Routing Information (10)3.2Hierarchical Abbreviation of IP Reachability Information (11)3.3Addressing Routers in IS−IS Packets (14)3.4External Links (16)3.5Type of Service Routing (17)3.6Multiple LSPs and SNPs (17)3.7IP−Only Operation (18)3.8Encapsulation (18)3.9Authentication (19)3.10Order of Preference of Routes / Dijkstra Computation (19)4Subnetwork Dependent Functions (22)4.1Link Demultiplexing (22)4.2Multiple IP Addresses per Interface (23)4.3LANs, Designated Routers, and Pseudonodes (23)4.4Maintaining Router Adjacencies (24)4.5Forwarding to Incompatible Routers (25)5Structure and Encoding of PDUs (25)5.1Overview of IS−IS PDUs (25)5.2Overview of IP−Specific Information for IS−IS (26)5.3Encoding of IP−Specific Fields in IS−IS PDUs (28)6Security Considerations (38)7Author’s Address (39)8References (39)A Inter-Domain Routing Protocol Information (40)A.1Inter-Domain Information Type (40)A.2Encoding (40)B Encoding of Sequence Number Packets (42)Callon Page iiB.1Level 1 Complete Sequence Numbers PDU (43)B.2Level 2 Complete Sequence Numbers PDU (45)B.3Level 1 Partial Sequence Numbers PDU (47)B.4Level 2 Partial Sequence Numbers PDU (49)C Dijkstra Calculation and Forwarding (51)C.1SPF Algorithm for IP and Dual Use (51)C.2Forwarding of IP packets (57)D Use of the Authentication Field (62)D.1Authentication Field in IS-IS packets (62)D.2Authentication Type 1 - Simple Password (62)E Interaction of the Integrated IS-IS with Brouters (64)E.1The Problem (64)E.2Possible Solutions (65)Figures1ISO Hierarchical Address Structure (3)2An Example (13)3Encoding of Variable Length Fields (27)Callon Page iii1 Introduction: Overview of the ProtocolThe TCP/IP protocol suite has been growing in importance as a multi-vendor communications architecture. With the anticipated emergence of OSI, we expect coexistence of TCP/IP and OSI to continue for an extended period of time. There is a critical need for routers to support both IP traffic and OSI traffic in parallel.There are two main methods that are available for routing protocols to support dual OSI and IP routers. One method, known as “Ships in the Night”, makes use of completely independent rout-ing protocols for each of the two protocol suites. This specification presents an alternate ap-proach, which makes use of a single integrated protocol for interior routing (i.e., for calculating routes within a routing domain) for both protocol suites.This integrated protocol design is based on the OSI Intra-domain IS-IS routing protocol [1], with IP-specific functions added. This RFC is considered a companion to the OSI IS-IS Routing spec, and will only describe the required additional features.By supporting both IP and OSI traffic, this integrated protocol design supports traffic to IP hosts, OSI end systems, and dual end systems. This approach is “integrated” in the sense that the IS-IS protocol can be used to support pure-IP environments, pure-OSI environments, and dual environ-ments. In addition, this approach allows interconnection of dual (IP and OSI) routing domains with other dual domains, with IP-only domains, and with OSI-only domains.The protocol specified here is based on the work of the IETF IS-IS working group.1.1 What the Integrated IS-IS offersThe integrated IS-IS provides a single routing protocol which will simultaneously provide an effi-cient routing protocol for TCP/IP, and for OSI. This design makes use of the OSI IS-IS routing protocol, augmented with IP-specific information. This design provides explicit support for IP subnetting, variable subnet masks, TOS-based routing, and external routing. There is provision for authentication information, including the use of passwords or other mechanisms. The precise form of authentication mechanisms (other than passwords) is outside of the scope of this docu-ment.Both OSI and IP packets are forwarded “as is” — i.e., they are transmitted directly over the un-derlying link layer services without the need for mutual encapsulation. The integrated IS-IS is a dynamic routing protocol, based on the SPF (Dijkstra) routing algorithm.The protocol described in this specification allows for mixing of IP-only, OSI-only, and dual (IP and OSI) routers, as defined below.An IP-only IS-IS router (or “IP-only” router) is defined to be a router which: (i) Uses IS-IS as the routing protocol for IP, as specified in this report; and (ii) Does not otherwise support OSI proto-cols. For example, such routers would not be able to forward OSI CLNP packets.Callon Page 1An OSI-only router is defined to be a router which uses IS-IS as the routing protocol for OSI, as specified in [1]. Generally, OSI-only routers may be expected to conform to OSI standards, and may be implemented independent of this specification.A dual IS-IS router (or “dual” router) is defined to be a router which uses IS-IS as a single inte-grated routing protocol for both IP and OSI, as specified in this report.This approach does not change the way that IP packets are handled. IP-only and dual routers are required to conform to the requirements of Internet Gateways [4]. The integrated IS-IS protocol described in this report outlines an Interior Gateway Protocol (IGP) which will provide routing within a TCP/IP routing domain (i.e., autonomous system). Other aspects of router functionality (e.g., operation of ICMP, ARP, EGP, etc.) are not affected by this proposal.Similarly, this approach does not change the way that OSI packets are handled. There will be no change at all to the contents nor to the handling of ISO 8473 Data packets and Error Reports, nor to ISO 9542 Redirects and ES Hellos. ISO 9542 IS Hellos transmitted on LANs are similarly unchanged. ISO 9542 IS Hellos transmitted on point-to-point links are unchanged except for the addition of IP-related information. Similarly, other OSI packets (specifically those involved in the IS-IS intra-domain routing protocol) remain unchanged except for the addition of IP-related information.This approach makes use of the existing IS-IS packets, with IP-specific fields added. Specifically: (i) authentication information may be added to all IS-IS packets; (ii) the protocols supported by each router, as well as each router’s IP addresses, are specified in ISO 9542 IS Hello, IS-IS Hello and Link State Packets; (iii) internally reachable IP addresses are specified in all Link State Pack-ets; and (iv) externally reachable IP addresses, and external routing protocol information, may be specified in level 2 Link State Packets. The detailed encoding and interpretation of this informa-tion is specified in sections 3, 4, and 5 of this RFC.The protocol described in this report may be used to provide routing in an IP-only routing do-main, in which all routers are IP-only. Similarly, this protocol may be used to provide routing in a pure dual domain, in which all routers are dual. Finally, this protocol may be used to provide routing in a mixed domain, in which some routers are IP-only, some routers are OSI-only, and some routers are dual. The specific topological restrictions which apply in this latter case are de-scribed in detail in section 1.4 (“Support of Mixed Routing Domains”). The use of IS-IS for sup-port of pure OSI domains is specified in [1].This protocol specification does not constrain which network management protocol(s) may be used to manage IS-IS-based routers. Management information bases (MIBs) for managing IP-only, OSI-only, and dual routers, compatible with CMIP, CMOT, and/or SNMP, are the subject of a separate, companion document [8].1.2 Overview of the ISO IS-IS ProtocolThe IS-IS Routing Protocol has been developed in ISO to provide routing for pure OSI environ-ments. In particular, IS-IS is designed to work in conjunction with ISO 8473 (The ISO Connec-tionless Network Layer Protocol [2]), and ISO 9542 (The ISO End System to Intermediate Sys-Callon Page 2tem Protocol [3]). This section briefly describes the manner in which IS-IS is used to support pure OSI environments. Enhancements for support of IP and dual environments are specified elsewhere in this report.In IS-IS, the network is partitioned into “routing domains”. The boundaries of routing domains are defined by network management, by setting some links to be “exterior links”. If a link is marked as “exterior”, no IS-IS routing messages are sent on that link.Currently, ISO does not have a standard for inter-domain routing (i.e., for routing between sepa-rate autonomous routing domains). Instead, manual configuration is used. The link is statically configured with the set of address prefixes reachable via that link, and with the method by which they can be reached (such as the DTE address to be dialed to reach that address, or the fact that the DTE address should be extracted from the IDP portion of the ISO address).OSI IS-IS routing makes use of two-level hierarchical routing. A routing domain is partitioned into “areas”. Level 1 routers know the topology in their area, including all routers and end sys-tems in their area. However, level 1 routers do not know the identity of routers or destinations outside of their area. Level 1 routers forward all traffic for destinations outside of their area to a level 2 router in their area. Similarly, level 2 routers know the level 2 topology, and know which addresses are reachable via each level 2 router. However, level 2 routers do not need to know the topology within any level 1 area, except to the extent that a level 2 router may also be a level 1 router within a single area. Only level 2 routers can exchange data packets or routing information directly with external routers located outside of the routing domains.As illustrated in figure 1, ISO addresses are subdivided into the Initial Domain Part (IDP), and the Domain Specific Part (DSP). The IDP is the part which is standardized by ISO, and specifies the format and authority responsible for assigning the rest of the address. The DSP is assigned by whatever addressing authority is specified by the IDP. The DSP is further subdivided into a “High Order Part of DSP” (HO-DSP), a system identifier (ID), and an NSAP selector (SEL). The HO-DSP may use any format desired by the authority which is identified by the IDP. Together, the combination of [IDP, HO-DSP] identify both the routing domain and the area within the rout-ing domain. The combination of [IDP,HO-DSP] may therefore be referred to as the “Area Ad-dress”.Callon Page 3Usually, all nodes in an area have the same area address. However, sometimes an area might have multiple addresses. Motivations for allowing this are:-It might be desirable to change the address of an area. The most graceful way of changing an area from having address A to having address B is to first allow it to have both addresses A and B, and then after all nodes in the area have been modified to recognize both addresses, then one by one the nodes can be modified to “forget” address A.-It might be desirable to merge areas A and B into one area. The method for accomplishing this is to, one by one, add knowledge of address B into the A partition, and similarly add knowledge of address A into the B partition.-It might be desirable to partition an area C into two areas, A and B (where “A” might equal “C”, in which case this example becomes one of removing a portion of an area). This would be accomplished by first introducing knowledge of address A into the appropriate nodes (those destined to become area A), and knowledge of address B into the appropriate nodes, and then one by one removing knowledge of address C.Since OSI addressing explicitly identifies the area, it is very easy for level 1 routers to identify packets going to destinations outside of their area, which need to be forwarded to level 2 routers. In IS-IS, there are two types of routers:-Level 1 intermediate systems — these nodes route based on the ID portion of the ISO ad-dress. They route within an area. They recognize, based on the destination address in a packet, whether the destination is within the area. If so, they route towards the destination. If not, they route to the nearest level 2 router.-Level 2 intermediate systems — these nodes route based on the area address (i.e., on the combination of [IDP, HO-DSP]). They route towards areas, without regard to the internal structure of an area. A level 2 IS may also be a level 1 IS in one area.A level 1 router will have the area portion of its address manually configured. It will refuse to become a neighbor with a node whose area addresses do not overlap its area addresses. However, if level 1 router has area addresses A, B, and C, and a neighbor has area addressesB and D, then the level 1 router will accept the other node as a neighbor.A level 2 router will accept another level 2 router as a neighbor, regardless of area address. How-ever, if the area addresses do not overlap, the link would be considered by both routers to be “level 2 only”, and only level 2 LSPs would flow on the link. External links (to other routing domains) must be from level 2 routers.IS-IS provides an optional partition repair function. In the unlikely case that a level 1 area be-come partitioned, this function, if implemented, allows the partition to be repaired via use of level 2 routes.IS-IS requires that the set of level 2 routers be connected. Should the level 2 backbone become partitioned, there is no provision for use of level 1 links to repair a level 2 partition.Callon Page 4In unusual cases, a single level 2 router may lose connectivity to the level 2 backbone. In this case the level 2 router will indicate in its level 1 LSPs that it is not “attached”, thereby allowing level 1 routers in the area to route traffic for outside of the domain to a different level 2 router. Level 1 routers therefore route traffic to destinations outside of their area only to level 2 routers which indicate in their level 1 LSPs that they are “attached”.An end system may autoconfigure the area portion of its address by extracting the area portion of a neighboring router’s address. If this is the case, then an endnode will always accept a router as a neighbor. Since the standard does not specify that the end system MUST autoconfigure its area address, an end system may be configured with an area address. In this case the end system would ignore router neighbors with non-matching area addresses.Special treatment is necessary for broadcast subnetworks, such as LANs. This solves two sets of issues: (i) In the absence of special treatment, each router on the subnetwork would announce a link to every other router on the subnetwork, resulting in n-squared links reported; (ii) Again, in the absence of special treatment, each router on the LAN would report the same identical list of end systems on the LAN, resulting in substantial duplication.These problems are avoided by use of a “pseudonode”, which represents the LAN. Each router on the LAN reports that it has a link to the pseudonode (rather than reporting a link to every other router on the LAN). One of the routers on the LAN is elected “designated router”. The designated router then sends out an LSP on behalf of the pseudonode, reporting links to all of the routers on the LAN. This reduces the potential n-squared links to n links. In addition, only the pseudonode LSP includes the list of end systems on the LAN, thereby eliminating the potential duplication (for further information on designated routers and pseudonodes, see [1]).The IS-IS provides for optional Quality of Service (QOS) routing, based on throughput (the de-fault metric), delay, expense, or residual error probability. This is described in greater detail in section 3.5, and in [1].1.3 Overview of the Integrated IS-ISThe integrated IS-IS allows a single routing protocol to be used to route both IP and OSI packets. This implies that the same two-level hierarchy will be used for both IP and OSI routing. Each area will be specified to be either IP-only (only IP traffic can be routed in that particular area), OSI-only (only OSI traffic can be routed in that area), or dual (both IP and OSI traffic can be routed in the area).This proposal does not allow for partial overlap of OSI and IP areas. For example, if one area is OSI-only, and another area is IP-only, then it is not permissible to have some routers be in both areas. Similarly, a single backbone is used for the routing domain. There is no provision for inde-pendent OSI and IP backbones.Similarly, within an IP-only or dual area, the amount of knowledge maintained by routers about specific IP destinations will be as similar as possible as for OSI. For example, IP-capable level 1 routers will maintain the topology within the area, and will be able to route directly to IP destina-tions within the area. However, IP-capable level 1 routers will not maintain information aboutCallon Page 5destinations outside of the area. Just as in normal OSI routing, traffic to destinations outside of the area will be forwarded to the nearest level 2 router. Since IP routes to subnets, rather than to specific end systems, IP routers will not need to keep nor distribute lists of IP host identifiers (note that routes to hosts can be announced by using a subnet mask of all ones).The IP address structure allows networks to be partitioned into subnets, and allows subnets to be recursively subdivided into smaller subnets. However, it is undesireable to require any specific relationship between IP subnet addresses and IS-IS areas. For example, in many cases, the dual routers may be installed into existing environments, which already have assigned IP and/or OSI addresses. In addition, even if IP addresses are not already pre-assigned, the address limitations of IP constrain what addresses may be assigned. We therefore will not require any specific rela-tionship between IP addresses and the area structure. The IP addresses can be assigned com-pletely independently of the OSI addresses and IS-IS area structure. As will be described in sec-tion 3.2 (“Hierarchical Abbreviation of IP Reachability Information”), greater efficiency and scaling of the routing algorithm can be achieved if there is some correspondence between the IP address assignment structure and the area structure.Within an area, level 1 routers exchange link state packets which identify the IP addresses reach-able by each router. Specifically, zero or more [IP address, subnet mask, metric] combinations may be included in each Link State Packet. Each level 1 router is manually configured with the [IP address, subnet mask, metric] combinations which are reachable on each interface. A level 1 router routes as follows:-If a specified destination address matches an [IP address, subnet mask, metric] reachable within the area, the packet is routed via level 1 routing.-If a specified destination address does not match any [IP address, subnet mask, metric] com-bination listed as reachable within the area, the packet is routed towards the nearest level 2 router.Flexible use of the limited IP address space is important in order to cope with the anticipated growth of IP environments. Thus an area (and by implication a routing domain) may simultane-ously make use of a variety of different address masks for different subnets in the area (or do-main). Generally, if a specified destination address matches more than one [IP address, subnet mask] pair, the more specific address is the one routed towards (the one with more "1" bits in the mask — this is known as "best match" routing).Level 2 routers include in their level 2 LSPs a complete list of [IP address, subnet mask, metric] specifying all IP addresses reachable in their area. As described in section 3, this information may be obtained from a combination of the level 1 LSPs (obtained from level 1 routers in the same area), and/or by manual configuration. In addition, Level 2 routers may report external reachabil-ity information, corresponding to addresses which can be reached via routers in other routing do-mains (autonomous systems)Default routes may be announced by use of a subnet mask containing all zeroes. Default routes should be used with great care, since they can result in “black holes”. Default routes are permit-Callon Page 6ted only at level 2 as external routes (i.e., included in the "IP External Reachability Information" field, as explained in sections 3 and 5). Default routes are not permitted at level 1.The integrated IS-IS provides optional Type of Service (TOS) routing, through use of the QOS feature from IS-IS.1.4 Support of Mixed Routing DomainsThe integrated IS-IS proposal specifically allows for three types of routing domains:-Pure IP-Pure OSI-DualIn a pure IP routing domain, all routers must be IP-capable. IP-only routers may be freely mixed with dual routers. Some fields specifically related to OSI operation may be included by dual rout-ers, and will be ignored by IP-only routers. Only IP traffic will be routed in an pure IP domain. Any OSI traffic may be discarded (except for the IS-IS packets necessary for operation of the routing protocol).In a pure OSI routing domain, all routers must be OSI-capable. OSI-only routers may be freely mixed with dual routers. Some fields specifically related to IP operation may be included by dual routers, and will be ignored by OSI-only routers. Only OSI traffic will be routed in a pure OSI domain. Any IP traffic may be discarded.In a dual routing domain, IP-only, OSI-only, and dual routers may be mixed on a per-area basis. Specifically, each area may itself be defined to be pure IP, pure OSI, or dual.In a pure IP area within a dual domain, IP-only and dual routers may be freely mixed. Only IP traffic can be routed by level 1 routing within a pure-IP area.In a pure-OSI area within a dual domain, OSI-only and dual routers may be freely mixed. Only OSI traffic can be routed by level 1 routing within a pure OSI area.In a dual area within a dual routing domain only dual routers may be used. Both IP and OSI traf-fic can be routed within a dual area.Within a dual domain, if both IP and OSI traffic are to be routed between areas then all level 2 routers must be dual.1.5 Advantages of Using Integrated IS-ISUse of the integrated IS-IS protocol, as a single protocol for routing both IP and OSI packets in a dual environment, has significant advantages over using separate protocols for independently routing IP and OSI traffic.Callon Page 7An alternative approach is known as “Ships In the Night” (S.I.N.). With the S.I.N. approach, completely separate routing protocols are used for IP and for OSI. For example, OSPF [5] may be used for routing IP traffic, and IS-IS [1] may be used for routing OSI traffic. With S.I.N., the two routing protocols operate more or less independently. However, dual routers will need to imple-ment both routing protocols, and therefore there will be some degree of competition for re-sources.Note that S.I.N. and the integrated IS-IS approach are not really completely separate options. In particular, if the integrated IS-IS is used within a routing domain for routing of IP and OSI traffic, it is still possible to use other independent routing protocols for routing other protocol suites.In the future, optional extensions to IS-IS may be defined for routing other common protocol suites. However, such future options are outside of the scope of this document. This section will compare integrated IS-IS and S.I.N. for routing of IP and OSI only.A primary advantage of the integrated IS-IS relates to the network management effort required. Since the integrated IS-IS provides a single routing protocol, within a single coordinated routing domain using a single backbone,, this implies that there is less information to configure. This combined with a single coordinated MIB simplifies network management.Note that the operation of two routing protocols with the S.I.N. approach are not really independ-ent, since they must share common resources. However, with the integrated IS-IS, the interac-tions are explicit, whereas with S.I.N., the interactions are implicit. Since the interactions are ex-plicit, again it may be easier to manage and debug dual routers.Another advantage of the integrated IS-IS is that, since it requires only one routing protocol, it uses fewer resources. In particular, less implementation resources are needed (since only one pro-tocol needs to be implemented), less CPU and memory resources are used in the router (since only one protocol needs to be run), and less network resources are used (since only one set of routing packets need to be transmitted). Primarily this translates into a financial savings, since each of these three types of resources cost money. This implies that dual routers based on the integrated IS-IS should be less expensive to purchase and operate than dual routers based on S.I.N.Note that the operation of two routing protocols with the S.I.N. approach are not really independ-ent, since they must share common resources. For example, if one routing protocol becomes un-stable and starts to use excessive resources, the other protocol is likely to suffer. A bug in one protocol could crash the other. However, with the integrated IS-IS, the interactions are explicit and are defined into the protocol and software interactions. With S.I.N., the interactions are im-plicit.The use of a single integrated routing protocol similarly reduces the likely frequency of software upgrades. Specifically, if you have two different routing protocols in your router, then you have to upgrade the software any time EITHER of the protocols change. If you make use of a single integrated routing protocol, then software changes are still likely to be needed, but less fre-quently.Callon Page 8。

中国移动统一DPI设备技术规范-LTE信令采集解析服务器接中国移动通信企业标准QB-╳╳-╳╳╳-╳╳╳╳中国移动统一D P I设备技术规范-L T E信令采集解析服务器接口规范Te c h n i c a l S p e c i f i c a t i o n o f D e e p P a c k e tI n s p e c t i o n E q u i p m e n t f o r C M C C(L T E S i g n a l l i n g C o l l e c t i o n S e r v e r I n t e r f a c eP a r t)版本号：2.0.9╳╳╳╳-╳╳-╳╳发布╳╳╳╳-╳╳-╳╳实施中国移动通信集团公司发布目录1范围 (4)2规范性引用文件 (4)3术语、定义和缩略语 (6)4接口在网络中的位置 (10)5LTE接口XDR数据构成方式 (11)5.1.XDR编号与上报要求126Uu接口XDR数据结构 (13)6.1.公共信息136.2.Uu接口信息166.3.Uu接口Keyword 1字段定义226.4.Uu接口事件流程开始/结束标识247X2接口XDR数据结构 (24)7.1.公共信息247.2.X2接口信息247.3.X2接口事件流程开始/结束标识328UE_MR XDR数据结构 (32)8.1.公共信息328.2.UE_MR信息329Cell_MR XDR数据结构 (37)9.1.公共信息379.2.Cell_MR信息3710S1-MME接口XDR数据结构 (39)10.1.公共信息3910.2.S1-MME接口信息3910.3.S1-MME接口Keyword 1字段定义5510.4.S1-MME接口Keyword 2字段定义5610.5.S1-MME接口事件流程开始/结束标识5711S1-U接口XDR数据结构 (57)12S6a 接口XDR数据结构 (57)12.1.公共信息5712.2.S6a接口信息5713S10、S11接口XDR数据结构 (62)13.1.公共信息6213.2.S10、S11接口信息6214S5/S8-C接口XDR数据结构 (72)14.1.公共信息7214.2.S5/S8-C接口信息7215SGs接口XDR数据结构 (79)15.1.公共信息7915.2.SGs接口信息7916Gn-C接口XDR数据结构 (85)16.1.公共信息8516.2.Gn-C接口信息8517基于XDR的原始码流上报 (90)17.1.原始码流上报功能9017.2.基于XDR上报原始码流的格式9017.3.按帧封装的原始码流要求9117.3.1.通用包头格式9217.3.2.专用包头格式9417.3.3.原始数据9418接口协议 (94)18.1.SDTP协议概述9418.2.消息类型9718.3.消息结构9918.4.连接管理流程10018.5.连接管理消息10218.5.1.版本协商verNego10318.5.1.1.请求10318.5.1.2.应答10318.5.2.链路认证linkAuth10418.5.2.1.请求10418.5.2.2.应答10618.5.3.链路检测linkCheck10718.5.3.1.请求10718.5.3.2.应答10718.5.4.链路数据发送校验linkDataCheck10818.5.4.1.请求10818.5.4.2.应答10918.5.5.链路释放linkRel11118.5.5.1.请求11118.5.5.2.应答11118.6.数据传输消息11218.6.1.XDR数据传输notifyXDRData11218.6.1.1.请求11218.6.1.2.应答11218.6.2.XDR对应原始码流传输XDRRawDataSend (113)18.6.2.1.请求11318.6.2.2.应答11319编制历史 (114)附录A：Uu/X2接口XDR事件流程和关键信令点116附录B：S1-MME接口XDR事件流程和关键信令点116前言本规范对中国移动网内使用的深度包检测（DPI）设备的功能和性能提出要求，是部署统一DPI设备需要遵从的技术文件。

Network Working Group R. Johnson Request for Comments: 3993 T. Palaniappan Category: Standards Track M. Stapp Cisco Systems, Inc. March 2005 Subscriber-ID Suboption for theDynamic Host Configuration Protocol (DHCP) Relay Agent OptionStatus of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (2005).AbstractThis memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol’s (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable"Subscriber-ID" with DHCP client messages in a way that isindependent of the client and of the underlying physical networkinfrastructure.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. Requirements Terminology . . . . . . . . . . . . . . . . . . . 23. The Subscriber-ID Suboption . . . . . . . . . . . . . . . . . 23.1. Suboption Format . . . . . . . . . . . . . . . . . . . . 34. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 35. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 46. Security Considerations . . . . . . . . . . . . . . . . . . . 47. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 7 Johnson, et al. Standards Track [Page 1]1. IntroductionDHCP (RFC 2131 [2]) provides IP addresses and configurationinformation for IPv4 clients. It includes a relay agent capabilityin which processes within the network infrastructure receivebroadcast messages from clients and forward them to DHCP servers asunicast messages. In network environments such as DOCSIS data-over- cable and xDSL, it has proven useful for the relay agent to addinformation to the DHCP message before forwarding it, by using therelay agent information option (RFC 3046 [3]).Servers that recognize the relay agent option echo it back in theirreplies, and some of the information that relays add may be used tohelp an edge device efficiently return replies to clients. Theinformation that relays supply can also be used in the server’sdecision making about the addresses and configuration parameters that the client should receive.In many service provider environments, it is desirable to associatesome provider-specific information with clients’ DHCP messages. This is often done by using the relay agent information option. RFC 3046 defines Remote-ID and Circuit-ID suboptions that are used to carrysuch information. The values of those suboptions, however, areusually based on a network resource such as an IP address of anetwork access device, an ATM Virtual Circuit identifier, or a DOCSIS cable-modem identifier. As a result, the values carried in thesesuboptions are dependent on the physical network configuration. If a client connects to the service provider network through differentpaths, different values are carried in network-dependent suboptions.2. Requirements TerminologyThe 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 RFC 2119 [1].3. The Subscriber-ID SuboptionIn complex service provider environments, connecting a customer’sDHCP configuration and administrative information is necessary. The Subscriber-ID suboption carries a value that can be independent ofthe physical network configuration through which the subscriber isconnected. This value complements, and might well be used inaddition to, the network-based relay agent option suboptionsdiscussed in Section 2. The "subscriber-id" assigned by the provider is intended to be stable as customers connect through differentpaths, and as network changes occur.Johnson, et al. Standards Track [Page 2]The Subscriber-ID information allows the service provider toassign/activate subscriber-specific actions; e.g., assignment of host IP address and subnet mask, DNS configuration, or trigger accounting. This suboption is de-coupled from the access network’s physicalstructure, so subscriber moves from one access-point to another, for example, would not require reconfiguration at the service provider’s DHCP servers.The Subscriber-ID is an ASCII string; the encoding of the string isdefined in Section 3.1. The semantic contents of the Subscriber-IDstring are, of course, provider-specific. This specification doesnot establish any semantic requirements on the data in the string.3.1. Suboption FormatThis memo defines a new DHCP relay agent option suboption thatcarries a "Subscriber-ID" value. The value is an ASCII string. The suboption takes a form similar to that of many other relayinformation option suboptions:0 1 2 3 4 5+-----+-----+-----+-----+-----+----+--|Code | Len | Subscriber-ID string ...+-----+-----+-----+-----+-----+----+--The Code for the suboption is 6.The one-octet Len field is the length of the ID string, in octets.The minimum length of the ID string is 1 octet.The "Subscriber-ID" is an NVT ASCII [4] string. The string MUST NOT be NULL terminated, as the length is specified in the "Len" field.4. Relay Agent BehaviorDHCP relay agents MAY be configured to include a Subscriber-IDsuboption if they include a relay agent information option in relayed DHCP messages. The subscriber-id strings themselves are assigned and configured through mechanisms that are outside the scope of thismemo.Johnson, et al. Standards Track [Page 3]5. DHCP Server BehaviorThis suboption provides additional information to the DHCP server.If it is configured to support this option, the DHCP server may usethis information in addition to other relay agent option data andother options included in the DHCP client messages in order to assign an IP address and/or other configuration parameters to the client.There is no special additional processing for this suboption.6. Security ConsiderationsMessage authentication in DHCP for intradomain use where the out-of- band exchange of a shared secret is feasible is defined in RFC 3118[5]. Potential exposures to attacks are discussed in section 7 ofthe DHCP protocol specification in RFC 2131 [2].The DHCP relay agent option depends on a trusted relationship between the DHCP relay agent and the server, as described in section 5 of RFC 3046. Fraudulent relay agent option data could potentially lead totheft-of-service or exhaustion of limited resources (like IPaddresses) by unauthorized clients. A host that tampered with relay agent data associated with another host’s DHCP messages could denyservice to that host, or interfere with its operation by leading the DHCP server to assign it inappropriate configuration parameters.While the introduction of fraudulent relay agent options can beprevented by a perimeter defense that blocks these options unless the relay agent is trusted, a deeper defense using authentication forrelay agent options via the Authentication Suboption [6] or IPSec [7] SHOULD be deployed as well.There are several data fields in a DHCP message conveying information that may identify an individual host on the network. These includethe chaddr, the client-id option, and the hostname and client-fqdnoptions. Depending on the type of identifier selected, theSubscriber-ID suboption may also convey information that identifies a specific host or a specific user on the network. In practice, thisinformation isn’t exposed outside the internal service-providernetwork, where DHCP messages are usually confined. Administratorswho configure data that’s going to be used in DHCP Subscriber-IDsuboptions should be careful to use identifiers that are appropriate for the types of networks they administer. If DHCP messages traveloutside the service-provider’s own network, or if the suboptionvalues may become visible to other users, that may raise privacyconcerns for the access provider or service provider.Johnson, et al. Standards Track [Page 4]7. IANA ConsiderationsIANA has assigned a value of 6 from the DHCP Relay Agent Information Option [3] suboption codes for the Subscriber-ID Suboption described in this document.8. AcknowledgementsThis document is the result of work done within Cisco Systems.Thanks especially to Andy Sudduth for his review comments.9. References9.1. Normative References[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,March 1997.[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,January 2001.[4] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.9.2. Informative References[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",RFC 3118, June 2001.[6] Stapp, M., "The Authentication Suboption for the DHCP RelayAgent Option", Work in Progress.[7] Droms, R., "Authentication of Relay Agent Options Using IPSec", Work in Progress.Johnson, et al. Standards Track [Page 5]Authors’ AddressesRichard JohnsonCisco Systems, Inc.170 W. Tasman Dr.San Jose, CA 95134USAPhone: 408.526.4000EMail: raj@Theyn PalaniappanCisco Systems, Inc.170 W. Tasman Dr.San Jose, CA 95134USAPhone: 408.526.4000EMail: athenmoz@Mark StappCisco Systems, Inc.1414 Massachusetts Ave.Boxborough, MA 01719USAPhone: 978.936.0000EMail: mjs@Johnson, et al. Standards Track [Page 6]Full Copyright StatementCopyright (C) The Internet Society (2005).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNETENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THEINFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can befound in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF at ietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Johnson, et al. Standards Track [Page 7]。