rfc3754.IP Multicast in Differentiated Services (DS) Networks
- 格式:pdf
- 大小:49.82 KB
- 文档页数:34
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。
DATA SHEETFortiSwitch ™ Data Center SeriesFortiSwitch Data Center switches deliver a Secure, Simple, Scalable Ethernet solution with outstanding throughput, resiliency, and scalability. Virtualization and cloud computing have created dense high-bandwidth Ethernet networking requirements. FortiSwitch Data Center switches meet these challenges by providing a high performance 10 GE, 40 GE, or 100 GE capable switching platform, with a low Total Cost of Ownership. Ideal for Top of Rack server or firewall aggregation applications, as well as SD-Branch network coredeployments, these switches are purpose-built to meetthe needs of today’s bandwidth intensive environments.Highlights§High throughput Ethernet switch suitable for Top of Rack or largeSD-Branch network deployments§ 1 GE, 10 GE, or 100 GE access ports, in a compact 1 RU form factor with 40 or 100 GE capable uplinks which includes breakout support for 2x50G, 4x25G, 4x10G, and 4x1G §FortiGate management through FortiLink, enabling the Security Fabric§Stackable up to 300 switches per FortiGate depending on model§Dual hot swappable power supplies for redundancy§Supports Wire-speed switching with both Store and Forward and Cut Through forwarding modesProduct OfferingsFortiSwitch 1024D, 1048E, 3032D, and 3032ESecurity Fabric Integration through FortiLinkThe FortiSwitch Data Center Series supports FortiGate managementthrough FortiLink, extending the Fortinet Security Fabric to the Ethernet port level. This link allows the same policies configured and applied to FortiGate interfaces to be applied to theFortiSwitch Ethernet ports, reducing complexity and decreasing management cost. With network security and access layer functions enabled and managed through a single console, centralized policy management, including role-based access and control, are easy to implement and manage. Users or devices can be authenticated against the same database and have the same security policy applied regardless of how or where they connect to the network.DATA SHEET | FortiSwitch™ Data Center SeriesDeploymentStandalone ModeThe FortiSwitch has a native GUI and CLI interface. All configuration and switch administration can be accomplished through either of theseinterfaces. Available ReSTful API’s offer additional configuration and management options.FortiLink ModeFortiLink is an innovative proprietary management protocol that allows our FortiGate Security Appliance to seamlessly manage any FortiSwitch. FortiLink enables the FortiSwitch to become a logical extension of the FortiGate integrating it directly into the Fortinet Security Fabric. This management option reduces complexity and decreases management cost as network security and access layer functions are enabled and managed through a single console.DATA SHEET | FortiSwitch ™ Data Center Series3HardwareFortiSwitch 3032D — frontFortiSwitch 3032D — backFortiSwitch 1048E — frontFortiSwitch 1048E — backFortiSwitch 1024D — backFortiSwitch 3032E — frontFortiSwitch 3032E — backFortiSwitch 1024D — frontDATA SHEET | FortiSwitch™ Data Center SeriesFeaturesLAG support for FortiLink Connection YesActive-Active Split LAG from FortiGate to FortiSwitches for Advanced Redundancy YesFORTISWITCH 1024D FORTISWITCH 1048E FORTISWITCH 3032D FORTISWITCH 3032E Layer 2Jumbo Frames Yes Yes Yes YesAuto-negotiation for port speed and duplex Yes Yes Yes YesIEEE 802.1D MAC Bridging/STP Yes Yes Yes YesIEEE 802.1w Rapid Spanning Tree Protocol (RSTP)Yes Yes Yes YesIEEE 802.1s Multiple Spanning Tree Protocol (MSTP)Yes Yes Yes YesSTP Root Guard Yes Yes Yes YesEdge Port / Port Fast Yes Yes Yes YesIEEE 802.1Q VLAN Tagging Yes Yes Yes YesPrivate VLAN Yes Yes Yes YesIEEE 802.3ad Link Aggregation with LACP Yes Yes Yes YesUnicast/Multicast traffic balance over trunking port(dst-ip, dst-mac, src-dst-ip, src-dst-mac, src-ip, src-mac)Yes Yes Yes YesIEEE 802.1AX Link Aggregation Yes Yes Yes YesSpanning Tree Instances (MSTP/CST)32/132/132/132/1IEEE 802.3x Flow Control and Back-pressure Yes Yes Yes YesIEEE 802.1Qbb Priority-based Flow Control Yes Yes Yes YesIEEE 802.3u 100Base-TX Yes No No YesIEEE 802.3z 1000Base-SX/LX Yes Yes Yes YesIEEE 802.3ab 1000Base-T Yes Yes No YesDATA SHEET | FortiSwitch™ Data Center Series Features* Requires ‘Advanced Features’ License5DATA SHEET | FortiSwitch™ Data Center Series RFC ComplianceRFC and MIB Support*BFDRFC 5880: Bidirectional Forwarding Detection (BFD)RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)RFC 5882: Generic Application of Bidirectional Forwarding Detection (BFD)BGPRFC 1771: A Border Gateway Protocol 4 (BGP-4)RFC 1965: Autonomous System Confederations for BGPRFC 1997: BGP Communities AttributeRFC 2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain RoutingRFC 2796: BGP Route Reflection - An Alternative to Full Mesh IBGPRFC 2842: Capabilities Advertisement with BGP-4RFC 2858: Multiprotocol Extensions for BGP-4RFC 4271: BGP-4RFC 6286: Autonomous-System-Wide Unique BGP Identifier for BGP-4RFC 6608: Subcodes for BGP Finite State Machine ErrorRFC 6793: BGP Support for Four-Octet Autonomous System (AS) Number SpaceRFC 7606: Revised Error Handling for BGP UPDATE MessagesRFC 7607: Codification of AS 0 ProcessingRFC 7705: Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute RFC 8212: Default External BGP (EBGP) Route Propagation Behavior without PoliciesRFC 8654: Extended Message Support for BGPDHCPRFC 2131: Dynamic Host Configuration ProtocolRFC 3046: DHCP Relay Agent Information OptionRFC 7513: Source Address Validation Improvement (SAVI) Solution for DHCPIP/IPv4RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IPRFC 5227: IPv4 Address Conflict DetectionRFC 5517: Cisco Systems' Private VLANs: Scalable Security in a Multi-Client EnvironmentRFC 7039: Source Address Validation Improvement (SAVI) FrameworkIP MulticastRFC 2362: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol SpecificationRFC 2710: Multicast Listener Discovery (MLD) for IPv6 (MLDv1)RFC 4541: Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping SwitchesRFC 4605: Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD)-Based Multicast Forwarding (“IGMP/MLD Proxying”)RFC 4607: Source-Specific Multicast for IPIPv6RFC 2464: Transmission of IPv6 Packets over Ethernet Networks: Transmission of IPv6 Packets over Ethernet NetworksRFC 2474: Definition of the Differentiated Services Field (DS Field) in the and IPv6 Headers (DSCP) RFC 2893: Transition Mechanisms for IPv6 Hosts and RoutersRFC 4213: Basic Transition Mechanisms for IPv6 Hosts and RouterRFC 4291: IP Version 6 Addressing ArchitectureRFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification RFC 4861: Neighbor Discovery for IP version 6 (IPv6)RFC 4862: IPv6 Stateless Address Auto configurationRFC 5095: Deprecation of Type 0 Routing Headers in IPv6RFC 6724: Default Address Selection for Internet Protocol version 6 (IPv6)RFC 7113: IPv6 RA GuardRFC 8200: Internet Protocol, Version 6 (IPv6) SpecificationRFC 8201: Path MTU Discovery for IP version 6IS-ISRFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual EnvironmentsRFC 5308: Routing IPv6 with IS-ISMIBMIBRFC 1724: RIPv2-MIBRFC 1850: OSPF Version 2 Management Information BaseRFC 2233: The Interfaces Group MIB using SMIv2RFC 2618: Radius-Auth-Client-MIBRFC 2620: Radius-Acc-Client-MIBRFC 2674: Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN extensionsRFC 2787: Definitions of Managed Objects for the Virtual Router Redundancy ProtocolRFC 2819: Remote Network Monitoring Management Information BaseRFC 2932: IPv4 Multicast Routing MIBRFC 2934: Protocol Independent Multicast MIB for IPv4RFC 3289: Management Information Base for the Differentiated Services ArchitectureRFC 3433: Entity Sensor Management Information BaseRFC 3621: Power Ethernet MIBRFC 6933: Entity MIB (Version 4)OSPFRFC 1583: OSPF version 2RFC 1765: OSPF Database OverflowRFC 2328: OSPF version 2RFC 2370: The OSPF Opaque LSA OptionRFC 2740: OSPF for IPv6RFC 3101: The OSPF Not-So-Stubby Area (NSSA) OptionRFC 3137: OSPF Stub Router AdvertisementRFC 3623: OSPF Graceful RestartRFC 5340: OSPF for IPv6 (OSPFv3)RFC 5709: OSPFv2 HMAC-SHA Cryptographic AuthenticationRFC 6549: OSPFv2 Multi-Instance ExtensionsRFC 6845: OSPF Hybrid Broadcast and Point-to-Multipoint Interface TypeRFC 6860: Hiding Transit-Only Networks in OSPFRFC 7474: Security Extension for OSPFv2 When Using Manual Key ManagementRFC 7503: OSPF for IPv6RFC 8042: CCITT Draft Recommendation T.4RFC 8362: OSPFv3 Link State Advertisement (LSA) ExtensibilityOTHERRFC 2030: SNTPRFC 3176: InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed NetworksRFC 3768: VRRPRFC 3954: Cisco Systems NetFlow Services Export Version 9RFC 5101: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow InformationRFC 5798: VRRPv3 (IPv4 and IPv6)RADIUSRFC 2865: Admin Authentication Using RADIUSRFC 2866: RADIUS AccountingRFC 5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)RIPRFC 1058: Routing Information ProtocolRFC 2080: RIPng for IPv6RFC 2082: RIP-2 MD5 AuthenticationRFC 2453: RIPv2RFC 4822: RIPv2 Cryptographic AuthenticationSNMPRFC 1157: SNMPv1/v2cRFC 2571: Architecture for Describing SNMPDATA SHEET | FortiSwitch ™ Data Center Series7Specifications* Full line rate with minimum packet size of 427bytes on FS-1048E** Fortinet Warranty Policy:/doc/legal/EULA.pdfDATA SHEET | FortiSwitch ™ Data Center Series8Specifications* Full line rate with minimum packet size of 250bytes on FS-3032E, 194bytes on FS-3032D ** Fortinet Warranty Policy:/doc/legal/EULA.pdfDATA SHEET | FortiSwitch™ Data Center Series Order InformationFS-SW-LIC-3000SW License for FS-3000 Series Switches to activate Advanced Features.AC Power Supply FS-PSU-460Spare AC power supply for FS-1048E/1024DFS-PSU-800Spare AC power supply for FS-3032E* When managing a FortiSwitch with a FortiGate via FortiGate Cloud, no additional license is necessary.For details of Transceiver modules, see the Fortinet Transceivers datasheet. Copyright © 2020 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.FST-PROD-DS-SW4FS-DC-DAT-R23-202011。
Interconnect routers complement IP edge and core router platforms to deliver enhanced, cost-effective IP network architectures. The 7250 IXR delivers a comprehensive set of IP/MPLS, synchronization and quality of service (QoS) capabilities. Flexible traffic management includes big buffering, per-port queuing, shaping and policing.High-density aggregationThe 7250 IXR is optimized for high-density aggregation, supporting up to 57.6 Tb/s(7250 IXR-10), 28.8 Tb/s (7250 IXR-6) or 1.6 Tb/s (7250 IXR-s) of system capacity, and is equipped with high-performance 100GE (Gigabit Ethernet), 50GE 2, 40GE, 25GE, 10GE and GE interfaces to scale networks to meet evolving traffic demands.Differentiated service supportPer-service, hierarchical queuing features support differentiated QoS, which is ideal for any-Gaggregation and fixed-mobile network convergence. These features also help industrial enterprises attain IT/OT (informational technology/operational technology) convergence by simultaneously carrying both their business and operational traffic.Nokia 7250 IXR-10/IXR-6/IXR-s Interconnect RoutersRelease 20The Nokia 7250 Interconnect Router (IXR) family addresses evolving demands driven by the cloud, 5G and the Internet of Things. The IXR-10, IXR-6 and IXR-s1 routers enable high-scale interconnectivity in data centers and across WANs and aggregation networks in service provider, enterprise and webscale environments.7250 IXR-107250 IXR-s7250 IXR-61 The 7250 IXR-10, IXR-6 and IXR-s are part of the 7250 IXR product family. Additional data sheets are available for other models in this product family.The 7250 IXR10, IXR-6 and IXR-s are referred to collectively as the 7250 IXR throughout this data sheet.2 50GE is a future software deliverable.High availabilityThe 7250 IXR sets the benchmark for high availability. The 7250 IXR-10 and IXR-6 systems support a full suite of 1+1 control, 5+1 fabric,and redundant fan and power configurations.In addition to full hardware redundancy, the robust Nokia Service Router Operating System (SR OS) supports numerous features to maximize network stability, ensuring that IP/MPLS protocols and services run without interruption. These features include innovative nonstop routing, nonstop services and stateful failover. AutomationThe 7250 IXR uses the Nokia SR OS and is managed by the Nokia Network Services Platform (NSP). The Nokia NSP offers a rich set of service management features that automate new service delivery and reduce operating cost.Standards-based software-defined networking (SDN) interfaces enable best-path computation to be offloaded to path computation elements (PCEs) such as the Nokia NSP. The 7250 IXR operates as a path computation client (PCC), collecting and reporting per-link and per-service delay, jitter and loss metrics as well as port utilization levels, for efficient path computation. Software featuresThe 7250 IXR supports, but is not limited to,the following features.Services• Point-to-point Ethernet pseudowires/virtual leased line (VLL)• Ethernet Virtual Private Network (EVPN)–Virtual Private Wire Service (EVPN-VPWS)–Virtual Private LAN Services (EVPN-VPLS):IPv4 and IPv6 support, including VirtualRouter Redundancy Protocol (VRRP)–Multihoming with single active or active/active • Multipoint Ethernet VPN services with VPLS based on Targeted Label Distribution Protocol (T-LDP) and Border Gateway Protocol (BGP)• Routed VPLS with Internet Enhanced Service (IES) or IP-VPN, IPv4 and IPv6• Ingress and egress VLAN manipulation for Layer 2 services• IP VPN (VPRN), Inter-Autonomous System (Inter-AS) Option A, B and C• IPv6 VPN Provider Edge (6VPE)Network protocols• Segment routing–Intermediate System-to-Intermediate System(SR-ISIS) and Open Shortest Path First(SR-OSPF)–Traffic engineering (SR-TE)• MPLS label edge router (LER) and label switching router (LSR) functions–Label Distribution Protocol (LDP)–Resource Reservation Protocol with trafficengineering (RSVP-TE)• BGP - Labeled Unicast (BGP-LU) (IETF RFC 3107) route tunnels• IP routing–Dual-stack Interior Gateway Protocol (IGP)–Multi-topology, multi-instance IntermediateSystem to Intermediate System (IS-IS)–Multi-instance OSPF–Multiprotocol BGP (MP-BGP)–BGP-LU support in edge, area border router(ABR) and autonomous system boundaryrouter (ASBR) roles–Usage-triggered download of BGP labelroutes to Label - Forwarding Information Base(L-FIB)–Accumulated IGP (AIGP) metric for BGP–BGP route-reflector for EVPN and IP-VPNwith VPNv4 and VPNv6 address families (AFs) • Layer 3 Multicast – base routing–Internet Group Management Protocol (IGMP)–Protocol Independent Multicast – Sparse Mode(PIM-SM), Source Specific Multicast (SSM)–Multicast Listener Discovery (MLD)• Layer 3 Multicast - VPRN (7250-IXR-s)–Next-generation multicast VPNs (NG-MVPN)–SSM with multicast LSPv4 (mLDPv4)–IGMP/MLD–IGMP/MLD on Routed VPLS Interface• Layer 2 Multicast–IGMP/MLD snoopingSDN• SR-TE LSPs, RSVP-TE LSPs–PCC initialized, PCC controlled–PCC initialized, PCE computed (7250 IXR-s)–PCC initialized, PCE controlled (7250 IXR-s)• SR-TE LSPs: PCE initialized, PCE controlled(7250 IXR-s)• Topology discovery: BGP-Link State (BGP LS) IPv4 and IPv6• Telemetry: streaming interface, service delay and jitter statisticsLoad balancing and resiliency• Nonstop routing (IXR-10 and IXR-6)• Segment routing topology independent and remote loop-free alternate (TI-LFA and rLFA)• LDP LFA• IEEE 802.3.ad Link Aggregation Group (LAG) and multi-chassis (MC) LAG• Pseudowire and LSP redundancy• IP and MPLS load balancing by equal-cost multipath (ECMP)• VRRP• Configurable polynomial and hash seed shift • Entropy label (IETF RFC 6790)• RSVP-TE Fast Reroute (FRR)• BGP Edge and Core Prefix Independent Convergence (BGP PIC)Platform• Ethernet IEEE 802.1Q (VLAN) and 802.1ad (QinQ) with 9k jumbo frames• Detailed forwarded and discarded countersfor service access points (SAPs) and network interfaces in addition to port-based statistics: per Virtual Output Queue (VoQ) packet and byte counters (7250 IXR-s)• Dynamic Host Configuration Protocol (DHCP) server for IPv4 IES, VPNv4• DHCP relay, IPv4 and IPv6, IES, IP-VPN,EVPN-VPLS• Accounting recordsQoS and traffic management• Hierarchical QoS (7250 IXR-s)–Hierarchical egress schedulers and shapersper forwarding class, SAP, network interfaceor port–Port sub-rate• Intelligent packet classification, including MAC, IPv4, IPv6 match-criteria-based classification • Granular rate enforcement with up to 32 policers per SAP/VLAN, including broadcast, unicast, multicast and unknown policers• Hierarchical policing for aggregate rate enforcement• Strict priority, weighted fair queuing schedulers • Congestion management via weighted random early discard (WRED)• Egress marking or re-markingSystem management• Network Management Protocol (SNMP)• Model-driven (MD) management interfaces–Netconf–MD CLI–Remote Procedure Call (gRPC)• Comprehensive support through Nokia NSPOperations, administration and maintenance • IEEE 802.1ag, ITU-T Y.1731: Ethernet Connectivity Fault Management for both fault detection and performance monitoring, including delay, jitter and loss tests• Ethernet bandwidth notification with egress rate adjustment• IEEE 802.3ah: Ethernet in the First Mile• Bidirectional Forwarding Detection IPv4 and IPv6• Two-Way Active Measurement Protocol (TWAMP), TWAMP Light• A full suite of MPLS OAM tools, including LSP and virtual circuit connectivity verification ping • Service assurance agent• Mirroring with slicing support:–Port–VLAN–Filter output: Media Access Control (MAC),IPv4/IPv6 filters–Local/remote• Port loopback with MAC swap• Configuration rollback• Zero Touch Provisioning (ZTP) capable (7250 IXR-s) Security• Remote Authentication Dial-In User Service (RADIUS), Terminal Access ControllerAccess Control System Plus (TACACS+), and comprehensive control-plane protection capabilities• MAC-, IPv4- and IPv6-based access control lists and criteria-based classifiers• Secure Shell (SSH)Hardware overview7250 IXR-10 and IXR-6 platformsThe 7250 IXR-10 and IXR-6 share common integrated media module (IMM) cards, control processor modules (CPMs) and power supplyunits (PSUs).Each chassis uses an orthogonal direct cross-connect architecture, with IMMs connecting in front and switch fabrics and fans connecting at the rear. The lack of a backplane, midplane or midplane connector system provides a compact chassis design, optimal cooling and easy capacity upgrades. The 7250 IXR supports a 5+1 switch fabric design for full fabric redundancy with graceful degradation. Fans and switch fabrics are separate, ensuring a complete separation of cooling from the dataplane and enabling non-service-impacting fan replacement options. The system uses a complete Faraday Cage design to ensure EMI containment, a critical requirement for platform evolution that will support next-generation application-specific integrated circuits (ASICs).7250 IXR-10 and IXR-6 control plane Control-plane performance is a key requirementin networking. Multicore CPUs with support for symmetric multiprocessing (SMP) provide leading capabilities in task distribution and concurrent processing, leveraging the hardened capabilitiesof the SR OS. This is a capability common to all platforms in the 7250 IXR product series.The 7250 IXR-10/IXR-6 supports dual-redundant CPMs for hot-standby control-plane redundancy and supports a fully distributed control infrastructure with dedicated CPUs per line card. Compared to single monolithic control plane systems, this distributed architecture provides optimized control plane processing without any detrimental impacts to the central CPM during system maintenance, IMM commissioning and heavy data loads. The distributed architecture also improves system security.Power suppliesThe 7250 IXR-10/IXR-6 platforms support 12and 6 PSUs respectively, allowing for full N+M(N is active and M is the number of protecting power supplies) power supply redundancy and full power feed redundancy. In contrast to systems with fewer power supplies, the 7250 IXR provides added headroom for power growth for system enhancements with next-generation ASICs.On the IXR-10/IXR-6, two PSU variants are available: a low-voltage DC PSU (LVDC) and a combined high-voltage DC (HVDC) and AC PSU. The PSUs are fully interchangeable between the chassis variants. The HVDC PSU option enables OPEX and CAPEX savings as a result of the power-supply and infrastructure design.The 7250 IXR-s supports two PSUs with 1+1 redundancy with support for either AC or LVDC power options.Technical specificationsTable 1. 7250 IXR6-10/IXR-6/IXR-s specificationsSystem configuration Dual hot-standby CPMs Dual hot-standby CPMs Single integrated CPM System throughput:Half duplex (HD) IMIXtraffic57.6 Tb/s28.8 Tb/s 1.6 Tb/sSwitch fabric capacity per module: Full duplex (FD) • 5.76 Tb/s• Single-stage fabric with gracefuldegradation• Separate fan tray from switch fabric• 2.88 Tb/s• Single-stage fabric with gracefuldegradation• Separate fan tray from switch fabricIntegratedCard slot throughput:FD per slot3.6 Tb/s 3.6 Tb/s n/aCard slots84n/aService interfaces n/a n/a• 6 x QSFP28/QSFP+100/40GE• 48 x SFP+/SFP 10/1GEControl interfaces Console, management, Synchronous Ethernet (SyncE)/1588, OES, BITS,Bluetooth, USB*, 1PPS, SD slot Console, management, USB, SD slotTiming and synchronization • Built-in Stratum 3E clock• ITU-T Synchronous Ethernet (SyncE)• IEEE 1588v2–Boundary clock (BC), slave clock (SC)–Profiles: IEEE 1588v2 default, ITU-T G.8275.1• Nokia Bell Labs IEEE 1588v2 algorithm• IETF RFC 5905 Network Time Protocol (NTP)• Building Integrated Timing Supply (BITS) ports (T1, E1, 2M) and pulse-persecond (1PPS) timing• Built-in Stratum 3E clock• ITU-T SyncE• ITU-T G.8262.1 eEEC• IEEE 1588v2–BC–Profile: ITU-T G.8275.1• ITU-T G.8273.2 Class B, C**• IETF RFC 5905 NTP• Support for GNSS SFPMemory buffer size Per card (see T able 2)Per card (see T able 2)8 GBRedundant hardware• Dual redundant CPMs• Switch fabric redundancy (5+1)• Power redundancy (M+N)• Fan redundancy (N+1)• Power redundancy (1+1)• Fan redundancy (5+1)Dimensions• Height: 57.78 cm (22.75 in);13 RU• Width: 44.45 cm (17.5 in)• Depth: 81.28 cm (32.0 in)Fits in standard 19-in rack • Height: 31.15 cm (12.25 in);7 RU• Width: 44.45 cm (17.5 in)• Depth: 81.28 cm (32.0 in)Fits in standard 19-in rack• Height: 4.35 cm (1.75 in);1 RU• Width: 43.84 cm (17.26 in)• Depth: 51.5 cm (20.28 in)Fits in standard 19-in rack* Future software deliverable** Class C for noise generation. Future support for RS-FEC.Power• 12 PSUs with N+M redundancy• LVDC (single feed): -40 V DC to-72 V DC• HVDC: 240 V to 400 V• AC: 200 V AC to 240 V AC,50 Hz/60 Hz• Front-bottom mounted • 6 PSUs with N+M redundancy• LVDC (single feed): -40 V DC to-72 V DC• HVDC: 240 V to 400 V• AC: 200 V AC to 240 V AC,50 Hz/60 Hz• Front-bottom mounted• 2 PSUs with 1+1redundancy• LVDC (single feed):-40 V DC/-72 V• AC: 200 V AC to 240 V AC,50 Hz/60 Hz• Rear mountedCooling• 3 trays of 3 ultra-quiet fans• Fan trays separate from switchfabric• Safety electronic breaks on removal• Front-to-back airflow• Fan filter door kit (optional)• 3 trays of 2 ultra-quiet fans• Fan trays separate from switchfabric• Safety electronic breaks on removal• Front-to-back airflow• Fan filter door kit (optional)• 6 trays of 1 ultra-quietfan each• Fan trays separate fromswitch fabric• Safety electronic breakson removal• Front-to-back airflowNormal operatingtemperature range0°C to +40°C (32°F to +104°F) sustainedShipping and storagetemperature-40°C to 70°C (-40°F to 158°F) Normal humidity5% to 95%, non-condensing Note: Throughout this table, n/a = not applicable.Optical breakout solutions available on QSFP28/QSFP+ ports:• 7210 IXR-10, IXR-6: 4 x 10GE and 4 x 25GE• 7210 IXR-s: 4 x 10GETable 2. Nokia 7250 IXR-10 and IXR-6 IMM cards36-port 100GE• 36 x 100GE QSFP28/QSFP+ 100/40GE• MACsec on all ports*• 48 GB packet buffer2-port 100GE + 48-port 10GE • 2 x 100GE QSFP28/QSFP+ 100/40GE • 48 x SFP+/SFP 10/1GE• MACsec on all ports*• 8 GB packet bufferTable 3. Platform density7250 IXR-s• 288 x 100/40GE• 384 x 10/1 GE + 16 x 100/40GE • 144 x 100/40GE• 192 x 10/1GE + 8 x 100/40GE• 6 x 100/40GE•48 x 10/1GE* Future software deliverableStandards compliance3Environmental• ATIS-0600015.03• ATT-TP-76200• ETSI EN 300 019-2-1; Storage Tests, (Class 1.2)• ETSI EN 300 019-2-2; Transportation Tests,(Class 2.3)• ETSI EN 300 019-2-3; Operational Tests, (Class 3.2)• ETSI EN 300 753 Acoustic Noise (Class 3.2)• GR-63-CORE• GR-295-CORE• GR-3160-CORE• VZ.TPR.9205• VZ.TPR.9203 (CO)Safety• AS/NZS 60950.1• CSA/UL 62368-1 NRTL• EN 62368-1 CE Mark• IEC 60529 IP20• IEC/EN 60825-1• IEC/EN 60825-2• IEC 62368-1 CB Scheme Electromagnetic compatibility• AS/NZS CISPR 32 (Class A)• ATIS-600315.01.2015• BSMI CNS13438 Class A• BT GS-7• EN 300 386• EN 55024• EN 55032 (Class A)• ES 201 468• ETSI EN 300 132-3-1• ETSI EN 300 132-2 (LVDC)• ETSI EN 300 132-3 (AC)• FCC Part 15 (Class A)• GR-1089-CORE• ICES-003 (Class A)• IEC 61000-3-2• IEC 61000-3-3• IEC CISPR 24• IEC CISPR 32 (Class A)• IEC 61000-6-2• IEC 61000-6-4• IEC/EN 61000-4-2 ESD• IEC/EN 61000-4-3 Radiated Immunity• IEC/EN 61000-4-4 EFT• IEC/EN 61000-4-5 Surge• IEC/EN 61000-4-6 Conducted Immunity • IEC/EN 61000-4-11 Voltage Interruptions • ITU-T L.1200• KCC Korea-Emissions & Immunity(in accordance with KN32/35)• VCCI (Class A)Directives, regional approvals and certifications • DIRECTIVE 2011/65/EU RoHS• DIRECTIVE 2012/19/EU WEEE• DIRECTIVE 2014/30/EU EMC• DIRECTIVE 2014/35/EU LVD• MEF CE 3.0 compliant• NEBS Level 3–Australia: RCM Mark–China RoHS: CRoHS–Europe: CE Mark–Japan: VCCI Mark–South Korea: KC Mark–Taiwan: BSMI Mark3 System design intent is according to the listed standards. Refer to product documentation for detailed compliance status.7Data sheetAbout NokiaWe create the technology to connect the world. Powered by the research and innovation of Nokia Bell Labs, we serve communications service providers, governments, large enterprises and consumers, with the industry’s most complete, end-to-end portfolio of products, services and licensing.From the enabling infrastructure for 5G and the Internet of Things, to emerging applications in digital health, we are shaping the future of technology to transformthe human experience. Nokia operates a policy of ongoing development and has made all reasonable efforts to ensure that the content of this document is adequate and free of material errors and omissions. Nokia assumes no responsibility for any inaccuracies in this document and reserves the right to change, modify, transfer, or otherwise revise this publication without notice.Nokia is a registered trademark of Nokia Corporation. Other product and company names mentioned herein may be trademarks or trade names of their respective owners. © 2020 NokiaNokia OyjKaraportti 3FI-02610 Espoo, Finland。
中移动家庭网关终端技术规范vThe document was finally revised on 2021中国移动通信企业标准QB-╳╳-╳╳╳-╳╳╳╳家庭网关终端技术规范T e c h n i c a l S p e c i f i c a t i o n f o r H o m e版本号:╳╳╳╳-╳╳-╳╳发布╳╳╳╳-╳╳-╳╳实施中国移动通信集团公司发布目录前言本标准明确了中国移动家庭网关需求,是家庭网关终端需要遵从的技术文件。
供中国移动内部和厂商共同使用,是实施家庭业务的依据之一。
本标准主要包括以下几方面内容:接口要求、功能要求、性能要求、网管和维护要求、软硬件系统要求以及运行环境等要求。
本标准是家庭网关设备系列标准之一,该系列标准的结构、名称或预计的名称如下:本标准需与《家庭网关业务技术规范》、《家庭网关业务技术规范—WLAN 共享分册》、《宜居通业务技术规范》、《家庭宽带类业务技术规范》、《家庭网关管理技术规范》、《宜居通终端技术规范》配套使用。
本标准的附录A、附录B为标准性附录。
本标准由中移号文件印发。
本标准由中国移动通信集团公司数据部提出,集团公司技术部归口。
本标准起草单位:中国移动通信研究院本标准主要起草人:张勇浩、梅海波、李建坤、刘聪、郭毅峰、陈心昕、黄薇、周丹、殷端、张彪、杨彦、刘松鹏、封栋梁、金波、叶朝阳1.范围本标准规定了中国移动家庭网关的设备形态、接口、功能、管理、安全、性能、运行环境、设备软硬件、基本应用和用户界面等要求,供中国移动通信集团内部使用,是开发研制接入型和宽带应用型家庭网关的技术依据。
本标准适用于2G/3G/4G移动网络、有线宽带网络环境。
2.规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。
CCIE 老版本SP2.0 考试v60++TOP样图CCIE ISP v3.0-Lab Equipment(2011年4月18日开始启用)• Cisco XR12000 Series Routers• Cisco 7200/7600 Series equivalent Routers (Using Simulator) • Cisco ME3400E Series SwitchesSoftware Versions• XR12000 routers running IOS-XR Software Version 3.9.1 • 7200/7600 routers running IOS Software Version 12.2-33 SR • ME3400E switches running IOS Software Version 12.2-54 SE IOS-XR will act as P and PE in lab, 7600 is using simulater in lab, there is no ES card, VPLS test on XR-12k.CCIE SP3.0将移除”面试环节”,将首次在SP考试中启用IPv6知识点!CCIE 运营商SP3.0考试详细大纲1. Implement, Optimize and Troubleshoot Core IP Technologies 1.1. Packet over SONET1.1.01. Cisco HDLC encapsulation1.1.02. PPP encapsulation1.1.03. Frame Relay encapsulation1.1.04. Maximum transmission unit (MTU)1.1.05. Cyclic redundancy check (CRC)1.1.06. Keepalive timer1.1.07. Frame Relay DLCI on point to point sub-interface1.1.08. SONET Controller1.1.09. POS channel1.1.10. Channelized SONET1.1.11. SONET APS1.2. IP over DWDM1.2.1. Optical channel payload unit (OPU)1.2.2. Optical channel data unit (ODU)1.2.3. Optical channel transport unit (OTU)1.2.4. Optical channel (OCh)1.2.5. Shared Risk Link Group (SRLG)1.2.6. Virtual Transponder (VTXP)1.2.7. FEC-FRR Triggering1.2.8. Optical Parameters- Rx-los-threshold, Wavelength and Transmit-power1.2.9. G.709 Parameters1.3. GE/10GE in the Core1.3.1. Gigabit Ethernet standards1.3.2. 10 Gigabit Ethernet standards1.3.3. Duplex mode1.3.4. MTU1.3.5. Flow control1.3.6. Link Aggregation Control Protocol (LACP)1.3.7. 802.1Q VLAN sub-interface1.4. SP high end product1.4.01. IOS-XR structure1.4.02. Install IOS-XR software1.4.03. Upgrade and manage IOS-XR software1.4.04. Secure domain router (SDR)1.4.05. CRS-1/3 structure1.4.06. CRS-1/3 Multi chassis1.4.07. Redundant Route Processors1.4.08. RP switchover1.4.09. MSC Architecture1.4.10. Switch Fabric Architecture1.5. IGP routing1.5.01. Network Service Access Point (NSAP)1.5.02. IS-IS Packet data unit (PDU)1.5.03. IS-IS hello1.5.04. IS-IS Link-state packets1.5.05. IS-IS Sequence Number Packets1.5.06. IS-IS area type1.5.07. IS-IS level1.5.08. IS-IS circuit type1.5.09. IS-IS Type Length Values (TLV)1.5.10. IS-IS Pseudo node1.5.11. IS-IS Designated Intermediate Systems 1.5.12. IS-IS SPF1.5.13. IS-IS LSP attached bit1.5.14. IS-IS LSP overload bit1.5.15. IS-IS Multi topology1.5.16. IS-IS Metric1.5.17. IS-IS support for IPv61.5.18. OSPF multi instance1.5.19. OSPF router-ID1.5.20. OSPF router type1.5.21. OSPF area1.5.22. OSPF hello1.5.23. OSPF LSA1.5.24. OSPF media type1.5.25. OSPF Designated Routers1.5.26. OSPF interface cost1.5.27. OSPF interface type1.5.28. OSPFv3 support for IPv61.5.29. EIGRP Diffusing Update Algorithm (DUAL) 1.5.30. EIGRP Composite Metrics1.5.31. EIGRP Hello1.5.32. EIGRP neighbor1.5.33. EIGRP Unequal Cost Load Sharing1.5.34. RIP v21.3.35. RIP support for IPv61.5.36. Redistribution between OSPF,IS-IS and EIGRP1.5.37. Redistribution of Directly connected routes1.5.38. Redistribution of Static routes1.5.39. Route summary1.5.40. IOS-XR routing policy language (RPL)1.5.41. Routing policy using route-map1.6. MPLS and LDP1.6.01. MPLS network component (P, PE, CE)1.6.02. MPLS label format1.6.03. MPLS label encapsulation1.6.04. MPLS label stack1.6.05. MPLS label operation1.6.06. Forwarding Equivalence Class1.6.07. Label Distribution Protocol (LDP)1.6.08. Label advisement model1.6.09. MPLS LDP—Local Label Allocation Filtering1.6.10. MPLS LDP-IGP synchronization1.6.11. MPLS LDP Inbound/outbound Label Binding Filtering1.6.12. Label Merging1.6.13. MPLS over ATM1.6.14. P2MP MPLS1.6.15. Multicast LDP(mLDP)1.7. MPLS Traffic Engineering1.7.01. TE Path calculation Constrained-Based Shortest Path First (CSPF)1.7.02. TE link information distribution1.7.03. RSVP support for TE path setup1.7.04. IS-IS support for TE1.7.05. OSPF support for TE1.7.06. Forwarding Traffic down Tunnel1.7.07. MPLS-TE Automatic Bandwidth1.7.08. MPLS-TE Static route1.7.09. MPLS-TE Auto route1.7.10. MPLS-TE Policy route1.7.11. MPLS-TE Forwarding adjacency1.7.12. MPLS-TE path metric1.7.13. MPLS-TE LSP attributes1.7.14. MPLS-TE Class-based Tunnel selection1.7.15. Pseudowire Tunnel Selection1.7.16. Point to multi point ( P2MP) MPLS TE1.7.17. Shared Risk Link Group (SRLG)1.7.18. Inter-Domain MPLS TE1.7.19. Inter-Area MPLS TE1.8. BGP1.8.01. BGP messages1.8.02. BGP neighbor1.8.03. BGP update1.8.04. BGP attributes1.8.05. BGP synchronization1.8.06. BGP routes aggregation1.8.07. BGP route reflector1.8.08. BGP confederation1.8.09. BGP Communites1.8.10. BGP Cluster list1.8.11. BGP Peer Groups1.8.12. IBGP IPv4/IPv6 Peering1.8.13. EBGP IPv4/IPv6 Peering1.8.14. EBGP IPv4/IPv6 multi hop peering1.8.15. BGP IPv4/IPv6 routes advertising1.8.16. EBGP IPv4/IPv6 peering using local-AS1.8.17. EBGP IPv4/IPv6 peering using AS-override1.8.18. BGP IPv4/IPv6 using private AS number1.8.19. Dual AS configuration for Network AS migration1.8.20. BGP Routing policy1.8.21. Redistributing IGP, static and connected route into BGP 1.8.22. BGP Multi-path Load Sharing1.8.23. BGP Link Bandwidth1.9. Multicast1.9.01.1 IPv4/IPv6 Multicast addressing1.9.01.2 Multicast distribution tree1.9.01.3 Multicast forwarding1.9.01.4 Multicast Reverse Path Forwarding (RPF)1.9.01.5 Multicast Administrative Boundaries1.9.01.6 PIM sparse mode for IPv4/IPv61.9.02. IPv4/IPv6 Multicast routing1.9.03. PIM Sparse Mode for IPv4/IPv61.9.04. IGMP V2/V31.9.05. IPV6 Multicast Listener Discover (MLD)1.9.06. PIM Source Specific Multicast (SSM) for IPv4/IPv61.9.07. Multicast Rate-limiting1.9.08. PIM Bidirectional (BiDir)1.9.09. PIM Static RP1.9.10. PIM Bootstrap Router (BSR)1.9.11. PIM Auto RP1.9.12. PIM Anycast RP1.9.13. Multicast Administrative Boundaries1.9.14. MSDP1.9.15. MP-BGP peer for Multicast1.9.16. MP-BGP Multicast route advertising1.9.17. Label switch multicast1.10. High Availability1.10.01. NSF/SSO for IGP routing1.10.02. NSF/SSO for BGP routing1.10.03. NSF/SSO for LDP, TE, Multicast1.10.04. HSRP, VRRP, GLBP1.10.05. Graceful Restart1.10.06. Control Plane Policing (CPP)1.10.07. Bidirectional forwarding detection (BFD)1.10.08. IP event dampening1.10.09. IGP Fast Re-route1.10.10. MPLS TE Fast Re-route (FRR)1.10.11. Link Protection using MPLS-TE1.10.12. Node Production using MPLS-TE1.10.13. Embedded event management (EEM)1.10.13. Hold-off Timer to Prevent Fast Reroute from Being Triggered (SONET)1.11. Convergence1.11.01. IS-IS fast convergence1.11.02. IS-IS to utilize the Overload Bit1.11.03. OSPF fast convergence1.11.04. BGP fast convergence1.11.05. BGP Route Dampening1.11.06. BGP Fast Peering Session Deactivation1.11.07. BGP Prefix Independent Convergence (PIC)1.11.08. BGP next hop tracking1.11.09. BGP address tracking filter1.11.10. BGP path MTU discovery1.11.11. IP fast reroute (IPFRR)1.11.12. Multicast-only Fast Re-Route (MoFRR)1.11.13. MPLS LDP convergence1.12. SP QoS1.12.01. Marking using DSCP, IP precedence and CoS1.12.02. Priority Queuing1.12.03. Custom Queuing1.12.04. Weighted Fair Queuing1.12.05. WRED1.12.06. Policing1.12.07. Class-based Weighted Faire Queuing (CB-WFQ) 1.12.08. Low-Latency Queuing (LLQ)1.12.09. Random-Detect using MQC1.12.10. NBAR for QoS1.12.11. MPLS EXP1.12.12. Differentiated Services Traffic Engineering (DS-TE) 1.12.13. Maximum Allocation Model (MAM)1.12.14. Russian Dolls Model (RDM)1.12.15. Class-Based Tunnel Selection: CBTS1.12.16. Policy-based Tunnel Selection: PBTS1.13. Security in core1.13.01. Standard Access-lists1.13.02. Extended Access-lists1.13.03. Routing Protocol Authentication for RIP V21.13.04. Routing Protocol Authentication for EIGRP1.13.05. Routing Protocol Authentication for OSPF1.13.06. Routing Protocol Authentication for IS-IS1.13.07. Routing Protocol Authentication for BGP1.13.08. BGP TTL Security Check1.13.09. Infrastructure ACL1.13.10. Anti Fragment Attacks1.13.11. Filtering RFC 1918 Routes1.13.12. uRPF for Anti-Spoofinng1.13.13. Selective packet discard (SPD)1.13.14. LDP authentication1.13.15. Remote triggered black hole (RTBH)1.13.16. NTP1.13.17. Attack mitigation1.13.18. SNMP Management1.13.19. IP packet Accounting1.13.20. Syslog2. Implement, Optimize and Troubleshoot Edge/Access Technologies2.1. FE/GE and Ethernet Trunk connections2.1.01. Ethernet Wire Service (EWS)2.1.02. Ethernet Relay Service (ERS)2.1.03. Ethernet Multipoint Service (EMS)2.1.04. Ethernet Flow Point (EFP)2.1.05. Ethernet Virtual Circuit (EVC)2.1.06. 802.1Q standard2.1.07. 802.1QinQ2.1.08. 802.1ad Provider Bridges (PB)2.1.09. 802.1ah Provider Backbone Bridge (PBB)2.1.10. Spanning Tree Protocol (STP)2.1.11. Resilient Ethernet Protocol (REP)2.1.12. Virtual Trunking Protocol (VTP)2.1.13. Flexible Service Mapping/Forwarding2.1.14. Ethernet Connectivity Fault Management (CFM)2.1.15. Ethernet channel2.2. PPP connections2.2.1. LCP2.2.2. NCP2.2.3. PPP encapsulation2.2.4. PPP multilink2.2.5. PPP Multi chassis multilink2.2.6. PPPoE client2.2.7. PPPoE server2.2.8. PPP authentication2.3. SONET/SDH connections2.3.1. SONET/SDH frame2.3.2. Automatic protection switching (APS), Timing2.3.3. Channelized SDH, channelized interface,2.4. Frame-relay connections2.4.1. Frame Relay PVC, SVC, DLCI2.4.2. Congestion-Control Mechanisms, FECN, BECN2.4.3. Discard Eligibility (DE) bit2.4.4. Frame Relay Fragmentation (FRF.12)2.4.5. Frame Relay FRF.9 Payload Compression2.4.6. Frame Relay Multilink (MLFR-FRF.16)2.4.7. Frame Relay Switching2.4.8. Frame-Relay LMI-Type2.4.9. PPP over Frame-Relay2.5. ATM connections2.5.1. ATM cell2.5.2. Virtual Path Identifier (VPI), Virtual Channel Identifier (VCI)2.5.3. Payload Type (PT), Cell Loss Priority (CLP)2.5.4. ATM adaptation layer (AAL)2.5.5. ATM addressing2.5.6. ATM PVC/SVC2.5.7. ATM Cell Loss Priority (CLP) Setting2.5.8. IP over ATM ( RFC1483)2.6. T1/T3 and E1/E3 services.2.6.1. Multiplexing2.6.2. Framing2.6.3. Timing2.6.4. Chanel group3. Describe, Implement, Optimize and Troubleshoot Remote Access Technologies3.1. IP over DSL to the customer3.1.1. PPPoA3.1.2. PPPoE over ATM3.1.3. L2TP between LAC and LNS3.1.4. RA (PPPoA,PPPoE over ATM) to VRF and MPLS VPN3.1.5. PPP authentication (Radius, TACACS)3.1.6. DHCP and options 823.2. IP over wire line to the customer3.2.1. PPP3.2.2. PPPoE3.2.3. L2TP between LAC and LNS3.2.4. PPPoE to VRF and MPLS VPN3.2.5. PPP authentication (Radius, TACACS)3.2.6. DHCP and options 823.2.7. Broadband network gateway (BNG)3.3. IP over Cable to the customer3.3.1. DOCSIS 3.03.3.2. PPPoE3.3.3. L2TP between LAC and LNS4. Implement, Optimize and Troubleshoot Layer 3 VPN4.1. Intra AS L3 MPLS VPN4.1.01. MP-IBGP VPNv4/VPNv6 peering4.1.02. MP-IBGP peering using loopback interface4.1.03. VPNv4/VPNv6 Route Reflector4.1.04. VRF definition4.1.05. Route Distinguisher4.1.06. Route Target4.1.07. Route Target import/export4.1.08. Intra AS MPLS VPNV4/VPNV6 load balancing4.1.09. SOO Community4.1.10. PE-CE – RIP V24.1.11. PE-CE – IS-IS4.1.12. PE-CE – OSPF4.1.13. PE-CE – EBGP4.1.14. PE-CE – Static Routes4.1.15. Redistributing dynamic PE-CE routes into VPNv4/VPNv6 4.1.16. Redistributing static PE-CE routes into VPNv4/VPNv64.1.17. Redistributing VPN4/VPNv6 routes into PE-CE routing table4.1.18. Intra-AS MPLS VPN multipath4.1.19. Intra-AS MPLS VPN path selection4.2. Inter AS L3 MPLS VPN4.2.1. MP-EBGP VPNv4/VPNv6 peering using direct interface4.2.2. MP-EBGP VPNv4/VPNv6 peer using multi-hop interface4.2.3. MP-EBGP VPNv4/VPNv6 peer between RRs4.2.4. VPNV4/VPNv6 next-hop unchanged4.2.5. VPNV4/VPNv6 next-hop self4.2.6. Multi VRF between ASPEs4.2.7. Inter-AS MPLS VPNV4/VPNv6 multipath4.2.8. Route target rewrite4.2.9. Inter-AS MPLS VPN path selection4.3. Carrier supporting carrier4.3.1. MPLS LDP in customer carrier site4.3.2. EBGPv4 + label between CSC-PE and CSC-CE4.3.3. IGP + LDP between CSC-PE and CSC-CE4.3.4. MPLS VPNv4 between customer carrier sites PEs4.3.5. CSC VPN load balancing4.3.6. VRF definition in customer carrier site4.3.7. Customer carrier site PE-CE routing4.4. VPN Extranet and internet access4.4.1. MP-BGP VPNv4/VPNv6 Extra-Net4.4.2. MP-BGP VPNv4/VPNv6 internet access4.5. VRF service4.5.1. Multiple VRF4.5.2. Multiple VRF routing4.5.3. VRF Selection based on Source IP Address4.6. Multicast VPN4.6.1. Default MDT4.6.2. Data MDT4.6.3. MP-BGP mdt peering4.6.4. Multicast routing in VPN site4.6.5. PM-SM in VPN site4.6.6. RP in VPN site4.6.7. Multicast VPN extranet4.7. GRE L3 VPN4.7.1. MPLS VPN—L3VPN over GRE5. Implement, Optimize and Troubleshoot Layer 2 VPN 5.1. Atom5.1.01. Psuedowire-class5.1.02. EoMPLS –Ethernet over MPLS5.1.03. FRoMPLS –Frame Relay over MPLS5.1.04. HDLCoMPLS-HDLC over MPLS5.1.05. PPPoMPLS-PPP over MPLS5.1.06. AAL5oMPLS-ATM AAL5 over MPLS5.1.07. L2TPv35.1.08. FR/PPP/HDLC/Ethernet interworking over MPLS 5.1.09. FR/PPP/HDLC/Ethernet interworking over L2TPv3 5.1.10. L2VPN local switching5.2. VPLS and Carrier Ethernet5.2.1. VPLS5.2.2. H-VPLS5.2.3. VFI definition5.2.4. VPLS BGP auto discovery5.2.5. VLAN attached circuit5.2.6. QinQ attached circuit5.2.7. 802.1ad attached circuit5.2.8. 802.1ah attached circuit5.2.9. VPLS/H-VPLS redundancy5.3. L2TPV3 for L2VPN5.3.1. L2TPv35.3.2. L2TPv3 VPN local switching5.3.3. L2TPv3 VPN interworking5.4. GRE L2VPN5.4.1. L2VPN over GRE6. Implement, Optimize and Troubleshoot Managed Services Traversing the Core6.1. Managed Voice/Video services traversing the core6.1.1. Traverse Voice/video packet6.1.2. Traverse call signal packet6.2. Managed Security services traversing the core6.2.1. Traverse IKE packet6.2.2. Traverse ESP, AH packet6.2.3. Traverse SSL packet6.3. Service Level Agreements for managed services6.3.1. IP SLA sender6.3.2. IP SLA responder6.3.3. IP SLA for MPLS VPN6.3.4. Netflow6.3.5. Netflow for MPLS6.3.6. Netflow for Multicast7. Describe Service Provider Network implementing principle7.1 Given a Service Provider network design change or new service, identify the success criteria7.2 Given a Service Provider network design change or new service, identify appropriate routing protocol7.3 Given a Service Provider network design change or new service, identify appropriate tunneling protocol7.4 Given a Service Provider network design change or new service, identify improving convergence method7.5 Given a Service Provider network design change or new service, identify improving stability method7.6 Given a Service Provider network design change or new service, identify improving reliability method7.7 Given a Service Provider network design change or new service, identify improving management method7.8 Given a Service Provider network design change or new service, identify improving QOS method7.9 Given a Service Provider network design change or new service, identify improving security。
IP分类技术研究∗喻中超吴建平徐恪(清华大学计算机科学与技术系北京 100084)摘要作为网络互联的核心设备,路由器必须以吉比特乃至更高的速度对IP包进行处理。
网络应用的发展要求路由器除了具备传统的路由转发功能之外,还必须有能力支持防火墙、提供QoS、流量计费等一系列功能。
这些都要求路由器根据包头对IP包进行分类,根据分类完成对数据包的不同处理。
本文全面地介绍了IP分类技术研究的最新成果,总结了解决IP分类问题的一般思想和并详细介绍了IP分类的典型算法。
本文对其中三种算法在虚拟环境下做了评测,比较了它们的优缺点,最后指出了进一步的研究方向。
关键词IP分类查找 QoSStudy of IP Classification TechnologyStudy of IP Classification TechnologyYU Zhong-chao WU Jian-ping XU Ke(Department of Computer Science and Technology, Tsinghua University, Beijing, 100084)Abstract As the core of Internet,routers must process packets at Gbps or even higher speed. As the network applications develop, routers must also support those functions such as firewalls, provision of QoS or traffic billing etc. All these functions need classification of packets, based on which it is determined how different packets are processed subsequently. In this article, the authors survey the recent advances in the research of IP classification and summarize the general principles of solution towards IP classification. Typical algorithms are introduced in this article. The authors also evaluate three of them in a virtual environment and compare their pros and cons. Keywords IP classification lookup QoS1 前言Internet的高速发展要求底层能够提供足够的带宽([1]),不但需要高速的通讯链路,还需要高速的网络路由设备,即路由器。
Network Working Group R. Bless Request for Comments: 3754 Univ. of Karlsruhe Category: Informational K. Wehrle Univ. of Tuebingen April 2004 IP Multicast in Differentiated Services (DS) NetworksStatus of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2004). All Rights Reserved.AbstractThis document discusses the problems of IP Multicast use inDifferentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It alsosuggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 21.1. Management of Differentiated Services. . . . . . . . . . 22. Problems of IP Multicast in DS Domains . . . . . . . . . . . . 3 2.1. Neglected Reservation Subtree Problem (NRS Problem). . . 4 2.2. Heterogeneous Multicast Groups . . . . . . . . . . . . . 122.3. Dynamics of Any-Source Multicast . . . . . . . . . . . . 133. Solutions for Enabling IP-Multicast in DifferentiatedServices Networks. . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Solution for the NRS Problem . . . . . . . . . . . . . . 13 3.2. Solution for Supporting Heterogeneous Multicast Groups . 153.3. Solution for Any-Source Multicast. . . . . . . . . . . . 164. Scalability Considerations . . . . . . . . . . . . . . . . . . 165. Deployment Considerations. . . . . . . . . . . . . . . . . . . 176. Security Considerations. . . . . . . . . . . . . . . . . . . . 187. Implementation Model Example . . . . . . . . . . . . . . . . . 188. Proof of the Neglected Reservation Subtree Problem . . . . . . 19 8.1. Implementation of the Proposed Solution. . . . . . . . . 208.2. Test Environment and Execution . . . . . . . . . . . . . 219. Simulative Study of the NRS Problem and Limited Effort PHB . . 23 Bless & Wehrle Informational [Page 1]9.1. Simulation Scenario. . . . . . . . . . . . . . . . . . . 249.2. Simulation Results for Different Router Types. . . . . . 2610. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3111. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 3111.2. Informative References . . . . . . . . . . . . . . . . . 3112. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 3313. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34 1. IntroductionThis document discusses the problems of IP Multicast use inDifferentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It alsosuggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.The "Differentiated Services" (DiffServ or DS) approach [1, 2, 3]defines certain building blocks and mechanisms to offer qualitatively better services than the traditional best-effort delivery service in an IP network. In the DiffServ Architecture [2], scalability isachieved by avoiding complexity and maintenance of per-flow stateinformation in core nodes, and by pushing unavoidable complexity tothe network edges. Therefore, individual flows belonging to the same service are aggregated, thereby eliminating the need for complexclassification or managing state information per flow in interiornodes.On the other hand, the reduced complexity in DS nodes makes it morecomplex to use those "better" services together with IP Multicast(i.e., point-to-multipoint or multipoint-to-multipointcommunication). Problems emerging from this fact are described insection 2. Although the basic DS forwarding mechanisms also workwith IP Multicast, some facts have to be considered which are related to the provisioning of multicast resources. It is important tointegrate IP Multicast functionality into the architecture from thebeginning, and to provide simple solutions for those problems thatwill not defeat the already gained advantages.1.1. Management of Differentiated ServicesAt least for Per-Domain Behaviors and services based on the EF PHB,admission control and resource reservation are required [14, 15].Installation and updating of traffic profiles in boundary nodes isnecessary. Most network administrators cannot accomplish this taskmanually, even for long term service level agreements (SLAs).Furthermore, offering services on demand requires some kind ofsignaling and automatic admission control procedures.Bless & Wehrle Informational [Page 2]However, no standardized resource management architecture forDiffServ domains exists. The remainder of this document assumes that at least some logical resource management entity is available toperform resource-based admission control and allotment functions.This entity may also be realized in a distributed fashion, e.g.,within the routers themselves. Detailed aspects of the resourcemanagement realization within a DiffServ domain, as well as theinteractions between resource management and routers or end-systems(e.g., signaling for resources), are out of scope of this document.Protocols for signaling a reservation request to a DifferentiatedServices Domain are required. For accomplishing end-system signaling to DS domains, RSVP [4] may be used with new DS specific reservation objects [5]. RSVP provides support for multicast scenarios and isalready supported by many systems. However, application of RSVP in a DiffServ multicast context may lead to problems that are alsodescribed in the next section. The NSIS Working Group is currentlydefining new signaling protocols that may show a different behavior, but the WG has its current focus more on unicast flows than onmulticast flows.2. Problems of IP Multicast in DS DomainsAlthough potential problems and the complexity of providing multicast with Differentiated Services are considered in a separate section of [2], both aspects have to be discussed in greater detail. Thesimplicity of the DiffServ Architecture and its DS node types isnecessary to reach high scalability, but it also causes fundamentalproblems in conjunction with the use of IP Multicast in DS domains.The following subsections describe these problems for which a generic solution is proposed in section 3. This solution is as scalable asIP Multicast and needs no resource separation by using differentcodepoint values for unicast and multicast traffic.Because Differentiated Services are unidirectional by definition, the point-to-multipoint communication is also considered asunidirectional. In traditional IP Multicast, any node can sendpackets spontaneously and asynchronously to a multicast groupspecified by their multicast group address, i.e., traditional IPMulticast offers a multipoint-to-multipoint service, also referred to as Any-Source Multicast. Implications of this feature are discussed in section 2.3.For subsequent considerations we assume, unless stated otherwise, at least a unidirectional point-to-multipoint communication scenario in which the sender generates packets which experience a "better" Per-Hop-Behavior than the traditional default PHB, resulting in a service of better quality than the default best-effort service. In order to Bless & Wehrle Informational [Page 3]accomplish this, a traffic profile corresponding to the trafficconditioning specification has to be installed in the sender’s first DS-capable boundary node. Furthermore, it must be assured that thecorresponding resources are available on the path from the sender to all the receivers, possibly requiring adaptation of traffic profiles at involved domain boundaries. Moreover, on demand resourcereservations may be receiver-initiated.2.1. Neglected Reservation Subtree Problem (NRS Problem)Typically, resources for Differentiated Services must be reservedbefore they are used. But in a multicast scenario, group membership is often highly dynamic, thereby limiting the use of a sender-initiated resource reservation in advance. Unfortunately, dynamicaddition of new members of the multicast group using DifferentiatedServices can adversely affect other existing traffic if resourceswere not explicitly reserved before use. A practical proof of thisproblem is given in section 8.IP Multicast packet replication usually takes place when the packetis handled by the forwarding core (cf. Fig. 1), i.e., when it isforwarded and replicated according to the multicast forwarding table. Thus, a DiffServ capable node would also copy the content of the DSfield [1] into the IP packet header of every replicate.Consequently, replicated packets get exactly the same DS codepoint(DSCP) as the original packet, and therefore experience the sameforwarding treatment as the incoming packets of this multicast group. This is also illustrated in Fig. 1, where each egress interfacecomprises functions for (BA-) classification, traffic conditioning(TC), and queueing.Interface A IP Forwarding Interface B+-----------+ +--------------+ +-----------+MC-flow | | | replication | | egress |---->| ingress |---->|------+-------|----->|(class.,TC,|---->| | | | | | queueing) |+-----------+ | | | +-----------+| | || | | Interface C| | | +-----------+| | | | egress || +-------|----->|(class.,TC,|---->| | | queueing) |+--------------+ +-----------+Figure 1: Multicast packet replication in a DS nodeBless & Wehrle Informational [Page 4]Normally, the replicating node cannot test whether a correspondingresource reservation exists for a particular flow of replicatedpackets on an output link (i.e., its corresponding interface). This is because flow-specific information (e.g., traffic profiles) isusually not available in every boundary and interior node.When a new receiver joins an IP Multicast group, a multicast routing protocol (e.g., DVMRP [6], PIM-DM [7] or PIM-SM [8]) grafts a newbranch to an existing multicast tree in order to connect the newreceiver to the tree. As a result of tree expansion, missing per-flow classification, and policing mechanisms, the new receiver willimplicitly use the service of better quality, because of the "better" copied DSCP.If the additional amount of resources which are consumed by the newpart of the multicast tree are not taken into account by the domainresource management (cf. section 1.1), the currently provided quality of service of other receivers (with correct reservations) will beaffected adversely or even violated. This negative effect onexisting traffic contracts by a neglected resource reservation -- in the following designated as the Neglected Reservation Subtree Problem (NRS Problem) -- must be avoided under all circumstances. Strongadmission control policies at the domain boundary will not help toprevent this problem either, because the new flow that inadmissiblyconsumes resources has its origin inside the domain.One can distinguish two major cases of the NRS Problem. They show a different behavior depending on the location of the branching point. In order to compare their different effects, a simplistic example of a share of bandwidth is illustrated in Fig. 2 and is used in thefollowing explanations. Neither the specific PHB types nor theirassigned bandwidth share are important; however, their relativepriority with respect to each other is of importance.40% 40% 20%+--------------------+---------------------+------------+|Expedited Forwarding| Assured Forwarding | Best-Effort|+--------------------+---------------------+------------+---------------------------------------------------------->output link bandwidthFigure 2: An example bandwidth share of differentbehavior aggregatesBless & Wehrle Informational [Page 5]The bandwidth of the considered output link is shared by three types of services (i.e., by three behavior aggregates): ExpeditedForwarding, Assured Forwarding, and the traditional Best-Effortservice. In this example, we assume that routers perform strictpriority queueing, where EF has the highest, AF the middle, andBest-Effort the lowest assigned scheduling priority. Though notmandatory for an EF implementation, a strict non-preemptive priority scheduler is one implementation option as described in section 5.1.1 of RFC 3247 [15]. Were Weighted Fair Queueing (WFQ) to be used, the described effects would essentially also occur, but with minordifferences. In the following scenarios, it is illustrated that PHBs of equal or lower priority (in comparison to the multicast flow’sPHB) are affected by the NRS problem.The Neglected Reservation Subtree problem appears in two differentcases:o Case 1: If the branching point of the new subtree (at first only a branch) and the previous multicast tree is a (egress) boundarynode, as shown in Fig. 3, the additional multicast flow nowincreases the total amount of used resources for the corresponding behavior aggregate on the affected output link. The total amount will be greater than the originally reserved amount.Consequently, the policing component in the egress boundary nodedrops packets until the traffic aggregate is in accordance withthe traffic contract. But while dropping packets, the router can not identify the responsible flow (because of missing flowclassification functionality), and thus randomly discards packets, whether they belong to a correctly behaving flow or not. As aresult, there will no longer be any service guarantee for theflows with properly reserved resources.Bless & Wehrle Informational [Page 6]Sender+---+| S | DS domains+---+ / \.||............... / \ ................. || .<- ->. .. || . . .. +---+ +--+ +--+ *) +--+ +--+ +--+ +------+ . |FHN|===|IN|=====|BN|###########|BN|####|IN|######|BN|####|Recv.B| . +---+ +--+ +--+\\ +--+ +--+ +--+ +------+ . \\ \ . \\ . \ .. +--+ +--+ . \\ . \ .. |IN|-----|IN| . \\ . +--+ .. +--+ +--+ . \\ ..........|BN|... || \ . +------+ +--+. || \ . |Recv.A|.+--+ +--+. +------+|BN|........|BN|+--+ +--+||S: SenderRecv.x: Receiver xFHN: First-Hop NodeBN: Boundary NodeIN: Interior Node===: Multicast branch with reserved bandwidth###: Multicast branch without reservation*) Bandwidth of EF aggregated on the output link is higher thanactual reservation, EF aggregate will be limited in bandwidthwithout considering the responsible flow.Figure 3: The NRS Problem (case 1) occurs when ReceiverB joinsIn figure 3, it is assumed that receiver A is already attached to the egress boundary node (BN) of the first domain. Furthermore,resources are properly reserved along the path to receiver A andused by correspondingly marked packets. When receiver B joins the same group as receiver A, packets are replicated and forwardedalong the new branch towards the second domain with the same PHBas for receiver A. If this PHB is EF, the new branch possiblyexhausts allotted resources for the EF PHB, adversely affectingother EF users that receive their packets over the link that ismarked with the *). The BN usually ensures that outgoing traffic aggregates to the next domain are conforming to the agreed traffic conditioning specification. The egress BN will, therefore, droppackets of the PHB type that are used for the multicast flow.Bless & Wehrle Informational [Page 7]Other PHBs of lower or higher priority are not affected adversely in this case. The following example in Fig. 4. illustrates this for two PHBs.+------------------+---------------------+--------------+------+| Expedited Forw. | Expedited Forw. | Assured Forw.| BE || | | | || with reservation | excess flow | with reserv. | || | without reservation | | |+------------------+---------------------+--------------+------+| EF with and without reservation share | 40 % | 20% || 40% of reserved EF aggregate. | | || -> EF packets with reservation and | | || without reservation will be | | || discarded! | | |+------------------+---------------------+--------------+------+(a) Excess flow has EF codepoint+------------------+---------------------+--------------+------+| Expedited Forw. | Assured Forwarding | Assured Forw.| BE || | | | || with reservation | excess flow | with reserv. | || | without reservation | | |+------------------+---------------------+--------------+------+| | AF with & without reservation share| 20 % || | 40% of reserved EF aggregate. | || 40% | -> EF packets with reservation and | || | without reservation will be | || | discarded! | |+------------------+---------------------+--------------+------+(b) Excess flow has AF codepointFigure 4: Resulting share of bandwidth in a egressboundary node with a neglected reservation of(a) an Expedited Forwarding flow or (b) anAssured Forwarding flow.Fig. 4 shows the resulting share of bandwidth in cases when (a)Expedited Forwarding and (b) Assured Forwarding is used by theadditional multicast branch causing the NRS Problem. Assumingthat the additional traffic would use another 30% of the linkbandwidth, Fig. 4 (a) illustrates that the resulting aggregate of Expedited Forwarding (70% of the outgoing link bandwidth) isthrottled down to its originally reserved 40%. In this case, the amount of dropped EF bandwidth is equal to the amount of excessbandwidth. Consequently, the original Expedited ForwardingBless & Wehrle Informational [Page 8]aggregate (which had 40% of the link bandwidth reserved) is alsoaffected by packet losses. The other services, e.g., AssuredForwarding or Best-Effort, are not disadvantaged.Fig. 4 (b) shows the same situation for Assured Forwarding. Theonly difference is that now Assured Forwarding is solely affected by discards, as the other services will still get theirguarantees. In either case, packet losses are restricted to themisbehaving service class by the traffic meter and policingmechanisms in boundary nodes. Moreover, the latter problem (case 1) occurs only in egress boundary nodes because they areresponsible for ensuring that the traffic leaving theDifferentiated Services domain is not more than the followingingress boundary node will accept. Therefore, those violations of SLAs will already be detected and processed in egress boundarynodes.o Case 2: The Neglected Reservation Subtree problem can also occurif the branching point between the previous multicast tree and the new subtree is located in an interior node (as shown in Fig. 5).In Fig. 5, it is assumed that receivers A and B have alreadyjoined the multicast group and have reserved resourcesaccordingly. The interior node in the second domain startsreplication of multicast packets as soon as receiver C joins.Because the router is not equipped with metering or policingfunctions, it will not recognize any amount of excess traffic and will forward the new multicast flow. If the latter belongs to ahigher priority service, such as Expedited Forwarding, bandwidthof the aggregate is higher than the aggregate’s reservation at the new branch and will use bandwidth from lower priority services. Bless & Wehrle Informational [Page 9]Sender+---+| S | DS domains+---+ / \.||............... / \ ................. || .<- ->. .. || . . .. +---+ +--+ +--+ +--+ +--+ +--+ +------+ . |FHN|===|IN|=====|BN|===========|BN|====|IN|======|BN|===|Recv.B| . +---+ +--+ +--+\\ +--+ +--+ +--+ +------+ . \\ \ . \\ . # .. +--+ +--+ . \\ . # *) .. |IN|-----|IN| . \\ . +--+ .. +--+ +--+ . \\ ..........|BN|... || \ . +------+ +--+. || \ . |Recv.A| #.+--+ +--+. +------+ #|BN|........|BN| +------++--+ +--+ |Recv.C||| +------+FHN: First-Hop Node, BN: Boundary Node, Recv.x: Receiver xS: Sender, IN: Interior Node===: Multicast branch with reserved bandwidth###: Multicast branch without reservation*) Bandwidth of EF aggregated on the output link is higher thanactual reservation, EF aggregate will be limited in bandwidthwithout considering the responsible flowFigure 5: Neglected Reservation Subtree problem case 2after join of receiver CBless & Wehrle Informational [Page 10]The additional amount of EF without a corresponding reservation is forwarded together with the aggregate which has a reservation.This results in no packet losses for Expedited Forwarding as long as the resulting aggregate is not higher than the output linkbandwidth. Because of its higher priority, Expedited Forwardinggets as much bandwidth as needed and as is available. The effects on other PHBs are illustrated by the following example in Fig. 6. +------------------+---------------------+--------------+------+| Expedited Forw. | Expedited Forw. | Assured Forw.| BE || | | | || with reservation | excess flow | with reserv. | || | without reservation | | |+------------------+---------------------+--------------+------+| 40% | 30% | 30% | 0% |+------------------+---------------------+--------------+------+EF with reservation and the excess flow use together 70%of the link bandwidth because EF, with or without reservation,has the highest priority.(a) Excess flow has EF codepoint+------------------+---------------------+--------------+------+| Expedited Forw. | Assured Forw. | Assured Forw.| BE || | | | || with reservation | excess flow | with reserv. | || | without reservation | | |+------------------+---------------------+--------------+------+| 40% | 60% | 0% || | (10% loss) | |+------------------+---------------------+--------------+------+AF with reservation and the excess flow use together 60%of the link bandwidth because EF has the highest priority(-> 40%). 10% of AF packets will be lost.(b) Excess flow has AF codepointFigure 6: Resulting share of bandwidth in an interiornode with a neglected reservation of (a) anExpedited Forwarding flow or (b) an AssuredForwarding flowThe result of case 2 is that there is no restriction for Expedited Forwarding, but as Fig. 6 (a) shows, other services will beextremely disadvantaged by this use of non-reserved resources.Their bandwidth is used by the new additional flow. In this case, the additional 30% Expedited Forwarding traffic preempts resources from the Assured Forwarding traffic, which in turn preemptsBless & Wehrle Informational [Page 11]resources from the best-effort traffic, resulting in 10% packetlosses for the Assured Forwarding aggregate, and a complete lossof best-effort traffic. The example in Fig. 6 (b) shows that this can also happen with lower priority services like AssuredForwarding. When a reservation for a service flow with lowerpriority is neglected, other services (with even lower priority)can be reduced in their quality (in this case the best-effortservice). As shown in the example, the service’s aggregatecausing the NRS problem can itself be affected by packet losses(10% of the Assured Forwarding aggregate is discarded). Besidesthe described problems of case 2, case 1 will occur in the DSboundary node of the next DS domain that performs traffic metering and policing for the service aggregate.Directly applying RSVP to Differentiated Services would also resultin temporary occurrence of the NRS Problem. A receiver has to jointhe IP multicast group to receive the sender’s PATH messages, before being able to send a resource reservation request (RESV message).Thus, the join message on the link for receiving PATH messages cancause the NRS Problem, if this situation is not handled in a special way (e.g., by marking all PATH messages with codepoint 0 and dropping or re-marking all other data packets of the multicast flow).2.2. Heterogeneous Multicast GroupsHeterogeneous multicast groups contain one or more receivers, whichwould like to get another service or quality of service as the sender provides or other receiver subsets currently use. A very importantcharacteristic which should be supported by Differentiated Servicesis that participants requesting a best-effort quality only shouldalso be able to participate in a group communication which otherwise utilizes a better service class. The next better support forheterogeneity provides concurrent use of more than two differentservice classes within a group. Things tend to get even more complex when not only different service classes are required, but alsodifferent values for quality parameters within a certain serviceclass.A further problem is to support heterogeneous groups with differentservice classes in a consistent way. It is possible that someservices will not be comparable to each other so that one servicecannot be replaced by the other, and both services have to beprovided over the same link within this group.Because an arbitrary new receiver that wants to get the differentservice can be grafted to any point of the current multicast delivery tree, even interior nodes may have to replicate packets using thedifferent service. At a first glance, this seems to be aBless & Wehrle Informational [Page 12]contradiction with respect to simplicity of the interior nodes,because they do not even have a profile available and should nowconvert the service of quality of individual receivers.Consequently, in order to accomplish this, interior nodes have tochange the codepoint value during packet replication.2.3. Dynamics of Any-Source MulticastBasically, within an IP multicast group, any participant (actually,it can be any host not even receiving packets of this multicastgroup) can act as a sender. This is an important feature whichshould also be available in case a specific service other than best- effort is used within the group. Differentiated Services possess,conceptually, a unidirectional character. Therefore, for everymulticast tree implied by a sender, resources must be reservedseparately if simultaneous sending should be possible with a betterservice. This is even true if shared multicast delivery trees areused (e.g., with PIM-SM or Core Based Trees). If not enoughresources are reserved for a service within a multicast tree allowing simultaneous sending of more than one participant, the NRS problemwill occur again. The same argument applies to half-duplexreservations which would share the reserved resources by severalsenders, because it cannot be ensured by the network that exactly one sender sends packets to the group. Accordingly, the correspondingRSVP reservation styles "Wildcard Filter" and "Shared-ExplicitFilter" [4] cannot be supported within Differentiated Services. The Integrated Services approach is able to ensure the half-duplex nature of the traffic, because every router can check each packet for itsconformance with the installed reservation state.3. Solutions for Enabling IP-Multicast in Differentiated ServicesNetworksThe problems described in the previous section are mainly caused bythe simplicity of the Differentiated Services architecture.Solutions that do not introduce additional complexity need to beintroduced so as to not diminish the scalability of the DiffServapproach. This document suggests a straightforward solution for most of the problems.3.1. Solution for the NRS ProblemThe proposed solution consists conceptually of the following threesteps that are described in more detail later.Bless & Wehrle Informational [Page 13]。