ASON Architecture剖析
WSSFDSGDFSGDFS
ASON自动交换光网络简介.Protocol)和RSVP-TE(资源预约协议带流量扩展Resource Reservation Protocol--Traffic Extension)。
I-NNI是属于一个域内的控制平面实体间的双向控制接口。
由于在域内运行，一般是同一个设备商的设备，因此没有建议标准化，每个设备厂商可以使用专有的接口协议也可以使用众所周知的接口协议。
I-NNI接口使用协议包括路由协议和信令协议，路由协议可以是OSPF-TE(开放最短路径优先协议-带流量工程扩展OpenShortestPathFirst-Traffic Engineering)、IS-IS-TE(中间系统-中间系统路由协议-带流量工程扩展Intermediate System-Intermediate System-Traffic Engineering)或BGP(边界网关协议Border Gateway Protoco1)协议，信令协议主要是CR-LDP和RSVP-TE。
E-NNI是属于域间控制平面的不同实体间的双向控制接口，支持呼叫控制、资源发现、连接控制、连接选择、连接路由选择。
与I-NNI不同，它是在不同域间交换路由可达性信息，屏蔽了网络内部的拓扑信息。
对多层拓扑结构间的E-NNI信息交互尤其是标准化的难点和重点。
ASON主要由三个国际化标准组织在推进，IETF,OIF和ITU-T。
(1)IETFIETF的MPLS，到GMPLS是催生ASON产生的基础。
ASON使用的信令协议CR-LDP，RSVP-TE 都是IETF近来标准化的结果，而ASON的路由协议包括OSPF-TE，BGP，它们都在原先协议的基础上，对光网络发展的需求做了相应的扩展。
最新增加的LMP链路管理协议也在不断修订中。
(2)OIFOIF对ASON最值得肯定的工作是UNI1.0。
由于有了UNI1.0，数据设备厂商和电信设备厂商在设备自动化互联时有了充分可信赖的依据。
网络相关国家标准
标准号
Standard No.
中文标准名称
Standard Title in Chinese
英文标准名称
Standard Title in English
状态
State
备注
Remark
1
GB/T 32413-2015
网络游戏外挂防治
Online game cheating program prevention and control
现行
国标委综合[2010]87号
4
GB/T 32414-2015
网络游戏安全
Online game security
现行
国标委综合[2007]100号
5
GB/T 30269.302-2015
信息技术 传感器网络 第302部分：通信与信息交换：高可靠性无线传感器网络媒体访问控制和物理层规范
Information technology—Sensor network—Part 302: Communication and information exchange: Medium access control（MAC） and physical layer（PHY） specification for reliable wireless sensor networks
现行
国标委综合[2009]93号
8
GB/T 30269.401-2015
信息技术 传感器网络 第401部分：协同信息处理：支撑协同信息处理的服务及接口
Information technology—Sensor networks—Part 401: Collaborative information processing: Services and interfaces supporting collaborative information processing
核心网技术 ASON的三个平面的介绍及联系
ASON的三个平面的介绍及联系ITU-T提出的ASON体系结构包括3个平面，即传送平面、控制平面和管理平面。
与传统光网络相比，ASON最突出的特征是在传送网中引入了独立的控制平面，使光传送网具备了自动完成网络带宽分配和动态配置电路的能力。
控制平面主要负责控制网络的呼叫连接，通过信令交换完成传送平面的动态控制，如建立或者释放连接、连接失败时提供保护恢复等。
在ITU-T制定的ASON标准G.8080中，对ASON的控制平面作出如下要求：(1) 控制平面要实现对多种已有传送网的支持，包括G.803中定义的SONET/SDH 传送网以及G.872中定义的光传送网（OTN）；(2)控制平面的实现与具体采用的控制协议无关，即ASON控制平面对各种协议应该是透明的；(3) 针对传输平面网络资源分成子网管理这一情況，控制平面应该可以支持分域管理；(4)控制平面功能的具体实现与连接管理的方式无关，即连接管理可以是集中式、完全分布式或是两者的结合。
为了实现这样的光同络控制平面，G.8080中也给出了实现ASON控制平面所必需的一些组件，并对其主要功能进行了描述。
控制平面的组件大致可以分为策略和接纳控制组件、拓扑维护和路由功能组件以及用于连接管理的信令组件三大类，具体包括：自动发现代理组件、终端和适配操作组件、路由控制组件、链路资源管理组件、呼叫控制组件、连接控制组件、策略控制组件、协议控制组件以及各组件之间的接口等。
在网络运营时，控制平面组件协调各部分的工作，实现包括自动邻居和业务发现、受限路由计算以及分布式呼叫和连接管理等许多智能光网络应具备的功能。
从ITU-T对ASON控制平面的要求可以看出：一方面，G.8080标准对控制平面功能以及各个组件各自实现的功能和提供的接口进行了规范；但另一力面，却没有对实现这些功能的具体细节进行规定，这就给了科研机构以及网络运营商一定的自由发挥的余地。
理论上说来，只要能够满足G.8080及其它标准提出的要求的协议，就可以运用在ASON中，运营商也可以在实现过程中添加自己的増值业务。
expected_an_architecture_identifier_in_index_概述说明
expected an architecture identifier in index 概述说明1. 引言1.1 概述在软件开发过程中，我们经常会遇到一些错误信息。
其中一个常见的错误信息是"expected an architecture identifier in index"（在索引中期望找到一个架构标识符）。
这个错误信息可能出现在构建、编译或链接代码时，给开发人员带来困扰和挫败感。
本文将深入分析这个错误信息，并提供解决方案以及实例分析与比较评价，以帮助读者更好地理解和解决这个问题。
1.2 文章结构本文共分为五个部分：引言、正文、解决方案探讨、实例分析与比较评价以及结论和展望。
首先，在引言部分，我们将对这个错误信息进行概述，并介绍文章的结构。
接着，在正文部分，我们将详细介绍背景介绍、错误信息解读和常见原因分析。
然后，在解决方案探讨部分，我们将探讨并提供几种可能的解决方案。
紧接着是实例分析与比较评价部分，我们将通过具体的实例分析来对不同方案进行比较和评价。
最后，在结论和展望部分，我们将总结主要结论，并展望未来可能的发展方向。
1.3 目的本文的目的是帮助读者更好地理解和解决"expected an architectureidentifier in index"错误信息。
通过对背景介绍、错误信息解读和常见原因分析的讨论，读者将能够深入了解这个错误信息的来源和可能的原因。
同时，我们还将提供几种可能的解决方案，并通过实例分析进行比较和评价，以帮助读者选择最适合自己情况的解决方案。
最后，我们将总结主要结论，并对未来可能的发展方向进行展望。
希望本文能为读者提供有价值的参考，并在面对这个错误信息时能够更加深入和全面地理解和解决问题。
2. 正文:2.1 背景介绍在软件开发和编程的过程中，我们经常会遇到各种错误和异常。
其中一个常见的错误信息是"expected an architecture identifier in index"。
ISO七层模型详解
简介
OSI（Open System Interconnection）参考模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系，一般称为OSI参考模型或七层模型。它是一个七层的、抽象的模型，不仅包括一系列抽象的术语或概念，也包括具体的协议。
起源
OSI的大部分设计工作实际上只是Honeywell Information System公司的一个小组完成的，小组的技术负责人是Charlie Bachman。在70年代中期，这个小组主要是为了开发一些原型系统而成立的，主要关注数据库系统的设计。70年代中，为了支持数据库系统的访问，需要一个结构化的分布式通信系统体系结构。于是这个小组研究了现有的一些解决方案，其中包括IBM公司的SNA(System Network Architecture)、ARPANET（Internet的前身）的协议、以及为标准化的数据库正在研究中的一些表示服务（presentation services）的相关概念，在1977年提出了一个七层的体系结构模型，他们内部称之为分布式系统体系结构（DSA）。
Synopsys Platform Architect系统级分析和优化说明书
DATASHEETOverview Synopsys Platform Architect is a SystemC TLM standards-based graphical environment for capturing, configuring, simulating, and analyzing the system-level performance and power of multicore systems and next-generation SoC architectures.Platform Architect enables system designers to explore and optimize the hardware-software partitioning and the configuration of the SoC infrastructure, specifically the global interconnect and memory subsystem, to achieve the right system performance, power and cost.Its efficient turnaround time, powerful analysis views, and available IP models make Platform Architect the premier choice for system-level analysis and optimization of Arm AMBA®-based SoCs.Workload and Platform Authoring Architecture analysisand optimization forperformance andpowerPlatform ArchitectPlatform Architect is a production- proven solution used by leading systems OEMs and semiconductor companies worldwide.Highlights• Address the architecture challenges of Artificial Intelligence (AI)-enabled SoCs and multi-chip systems• Hardware-software partitioning and optimization of multicore systems• SoC interconnect and memory subsystem performance and power optimization• Efficient exploration using traffic generation and cycle-accurate TLM interconnect models• Unified view of activity, performance and power for root-cause analysis• Parameter sweeping and sensitivity analysis• Hardware-software validation using cycle-accurate TLM processor models• Compliant with IEEE 1666-2011 SystemC and TLM-2.0 as well as IEEE 1804 UPF 3.0 for system level power analysis Problem: Predicting System Performance and PowerPredicting the dynamic system performance and power of today’s multi-function, multi-application SoCs requires simulation.This impacts both system OEMs and semiconductor companies, and creates an opportunity for information sharing and collaboration within the supply chain.Challenges with Traditional MethodsDiscovering problems with system performance and power consumption late in the development cycle can be catastrophic to project schedules and product competitiveness, causing failure in the market. Accurate architecture analysis must be done earlier in the design cycle:• While spreadsheets are good for aggregating data, static spreadsheet calculations are not accurate enough to estimate performance and power and make design decisions. Dynamic simulation is needed.• Traditional RTL simulation is too slow and lacks the configurability and visibility to analyze performance. In addition,the RTL may simply not be available• Risks include over-design, under-design, cost increases, schedule delays, and re-spinsSolution: Dynamic System-Level Architecture Simulation and AnalysisSynopsys Platform Architect provides system designers with the dynamic transaction-level simulation of performance and power, rapid turnaround time, and powerful system-level visibility they need to greatly improve the analysis and decision-making process. Address the Architecture Challenges of AI SoCs and Multi-Chip SystemsEasily map AI workloads to different SoC architectures to resolve AI power and performance design challenges with Platform Architect. Quickly address challenges of evolving algorithms, highly parallel compute and high memory requirements, with• A library of configurable AI operators for modeling Convolutional Neural Networks (CNNs)• Automated import of workloads from AI frameworks via prototxt and ONNX• An example NVDLA performance model to rapidly represent custom AI acceleratorsAI Operator library CNN workload modelFigure 2: AI Exploration Pack for performance analysis of AI accelerators Hardware-Software Partitioning and Optimization of Multicore Systems Platform Architect enables architects to create task-based workload models of the end-product application for early architecture analysis.Product trends requiring analysis Dynamic workloads generated by multiple initiators and software stacks Highest processing and memory bandwidth requirements by AI applicationsComplex interconnect topologies with hierarchical arbitration and advanced QoS capabilitiesComplex memory hierarchies with caches, on-chip SRAM, off-chip DDRResults with Platform Architect Quantitative analysis results on Key Performance Indicators like effective operations per second, frame-rate, etc. Fast turn-around time for architectural 'what-if' experimentsMeasurable improvement in product performance and powerReduced schedule risk vs. traditional RTL-based methodsFigure 3: SoC performance analysis challenges and the benefits of using system-levelmethods for performance and power analysis in Synopsys Platform ArchitectGeneric task models are easily configured to create a SystemC performance model of the application, called a task-graph.• Using a task-graph, the performance workload of parallel application tasks are mapped onto Virtual Processing Unit (VPU) task-driven traffic generators• Simulation and task analysis enables hardware/software partitioning to be optimized for best system performanceand power well before the application software is available• Task graphs also model the traffic generated by the initiators enabling performance optimization of the interconnect and memory subsystem• Platform Architect includes a Task Graph Generator (TGG) tool that generates application task graphs from sofware execution traces, like VDK software analysis, Linux ftrace, Android atrace, or QNX kernel trace. The TGG can be customized to generate task graphs from custom software trace formats.Interconnect and Memory Subsystem Performance Optimization Using Synthetic and Trace-Driven Traffic GenerationPlatform Architect focuses on architecture design challenges associated with the optimization and performance validation of the backbone SoC interconnect and global memory subsystem:• Dynamic application workloads are modeled using traffic generation, enabling early measurement of system performance and power before software is available• Simulation sweeping enables analysis data to be collected parametrically, exploring all traffic scenarios against a wide range of architecture configurations• Powerful tools for analysis visualization provide graphical transaction tracing and statistical analysis views that enable identification of performance and power bottlenecks, determine their root-cause, and examine the sensitivity that system performance may have to individual or combined parameter settingsThe result is an executable specification used to carefully dimension the SoC interconnect and memory subsystem to support the latency, bandwidth, and power requirements of all relevant SoC components, under all operating conditions.Hardware/Software Performance Validation Using Processor Modelsand Critical SoftwareAfter exploration, the model of the candidate architecture can be refined to replace the task-based workload model with cycle- accurate processor models. This enables architects to validate the architecture candidate using the available performance critical software.Software and hardware analysis views can be visualized together to provide unique system-level visibility to measure performanceand power, and to confirm goals are met.Complete IEEE 1666-2011 SystemC TLM-2.0 Standards-Based EnvironmentSynopsys Platform Architect is a SystemC-based environment fully compatible with the IEEE 1666-2011 SystemC and TLM-2.0 Language Reference Manual (LRM). It supports the assembly, simulation and analysis of models containing mixed levels of abstraction, including:• Standards-based SystemC transaction-level models using IEEE 1666-2011 TLM-2.0 and Accellera Systems Initiative (ASI) TLM industry standards, and the open Synopsys SystemC Modeling Library (SCML) API library for highly reusable TLM-2.0 based peripheral modeling• Support for the IEEE 1804 UPF standard for the creation of system level power models. These can be connected to the TLM performance models to analyze the system-level power consumption based on dynamic activity.• M ixed SystemC/HDL co-simulation with Synopsys VCS and other third-party HDL simulation environments enabling reuse of RTL memory controllers and other IP components• A n Eclipse-based Integrated Development Environment for development and integration of SystemC based models, including a TLM Creation perspective for development and testing of SCML-based peripheral models and custom task models, as well as a TLM Debug perspective for SystemC aware source code debugging, tracing and analysisGetting Started with Available Architecture IP ModelsPlatform Architect supports the broadest commercially available portfolio of pre-instrumented SystemC TLM IP models for architecture exploration and validation.Task-based and Software-based Workload Modeling• G eneric Virtual Processing Units (VPUs) for application task-mapping with synthetic and trace-based traffic generation• Cycle-accurate SystemC-based TLM Arm Cycle Models, ARC nSim/nCam and xCAM models, Tensilica and MIPS processor families, and HDL co-simulation with user-provided RTL for other processor families• Accurate performance models of the DesignWare Embedded Vision (EV) subsystem, including nSim/nCAM model of the ARC Vector processor and the Fast Performance Model (FPM) of the Deep Neural Network (DNN) acceleratorInterconnect Models• Generic, fast, approximately-timed SystemC TLM models for AMBA-based coherent and non-coherent interconnect andnetwork-on-chip• Integration of architecture models for the Arteris FlexNoC™ Network on Chip (NoC) interconnect• C ycle-accurate SystemC TLM bus libraries for Arm CoreLink™ Network Interconnect and Synopsys DesignWare IPAXI interconnect• I ntegration of Arm Cycle Models for implementation accurate interconnect models of Arm coherent and non-coherent interconnects• F low for integration of 3rd-party interconnect models for full configurability in Platform Architect• G eneric configurable models of chip-to-chip protocols for PCIe and EthernetMemory Controller Models• Accurate SystemC TLM performance models of Synopsys DesignWare DDR memory controllers, including the DDR5/4 controller, the DDR5/4/4X controller and the enhanced Universal DDR Memory Controller (uMCTL2)• Generic approximately-timed SystemC TLM multi-port memory subsystem models for Arm AXI and CHI protocols• Cycle-accurate memory subsystem models through HDL co-simulation with user-provided, third-party, and Synopsys RTL memory controller IPProcessor Models• Cycle-accurate SystemC TLM processor support packages (PSPs) for Tensilica and MIPS processor families, and through HDL co-simulation with user-provided RTL for Arm processor familiesCoStart Enablement ServicesSynopsys CoStart is a packaged service that shortens the ramp-up cycle for architecture design methodologies so that users become productive in the shortest time.The Synopsys CoStart program contains an intense knowledge transfer, while assisting in architecture study project planning, use case traffic capture, architecture model creation, simulation, and analysis of results:• Tool, IP model, and methodology training that ensures end-user value at each step, accelerating results• Modeling services for the development and integration of custom interconnect and memory subsystem models, minimizing the modeling effort to get started and achieve initial value• Expert consulting and support to maximize ROI through exploration (not just checking)About Synopsys Virtual Prototyping SolutionsPlatform Architect is part of Synopsys’ comprehensive Virtual Prototyping solution offering that:• Provides the broadest portfolio of system-level IP models from a single supplier• Accelerates the creation and optimization of common SoC blocks• Facilitates SoC architecture exploration and optimization• Provides the most complete prototyping solutions to accelerate embedded software development and system validation• Includes comprehensive training materials and examples• Enables value throughout the semiconductor supply chainFor more information on Platform Architect visit: /platformarchitect©2021 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks isavailable at /copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners.。
sovits模型原理
sovits模型原理Sovits模型原理介绍Sovits模型是一种用于描述软件开发过程的模型，它是由美国软件工程师Barry W. Boehm在1981年提出的。
该模型基于著名的“螺旋模型”，但是在实践中更加灵活和可控。
Sovits模型的核心思想是通过不断迭代来完成软件开发过程，每个迭代都包括需求分析、设计、编码、测试和部署等阶段。
在每个迭代结束时，团队都会对当前阶段的成果进行评估，并根据评估结果调整下一个迭代的计划。
本文将详细介绍Sovits模型的原理及其应用。
1. 模型结构Sovits模型由以下几个部分组成：1.1 需求分析需求分析是软件开发过程中最重要的阶段之一。
在这个阶段，团队需要与客户沟通，了解客户对软件的需求和期望。
基于这些信息，团队可以制定一个详细的需求规格说明书，包括功能需求、性能需求、界面需求等。
1.2 设计设计是将需求转化为具体实现方案的过程。
在这个阶段，团队需要考虑软件的架构、模块划分、数据结构、算法等，以及如何实现各种功能需求。
1.3 编码编码是将设计方案转化为代码的过程。
在这个阶段，团队需要根据设计方案编写代码，并对代码进行测试和调试。
1.4 测试测试是确保软件质量的关键步骤。
在这个阶段，团队需要对软件进行各种测试，包括单元测试、集成测试、系统测试等，以确保软件能够满足所有需求规格说明书中的要求。
1.5 部署部署是将软件交付给客户或用户的过程。
在这个阶段，团队需要将软件安装到目标环境中，并进行必要的配置和调试。
2. 迭代过程Sovits模型通过不断迭代来完成软件开发过程。
每个迭代都包括上述五个阶段，但在不同迭代中可能会有所不同。
每个迭代都有一个明确的目标和计划，并且在结束时需要对当前阶段的成果进行评估。
2.1 目标与计划每个迭代都有一个明确的目标和计划。
目标通常是针对当前阶段的某些具体需求或问题而制定的，例如改进软件性能、增加新功能等。
计划包括详细的任务分配、时间表和资源需求等。
通俗易懂解释soa架构
通俗易懂解释soa架构
SOA（Service-Oriented Architecture，面向服务的架构）是一种软件架构方法，它将应用程序的不同功能单元（称为服务）进行封装，并定义清晰的接口以便于其他服务调用。
这些服务通常以可重复的方式执行具体的业务功能，使得它们可以与其他服务进行交互以完成复杂的业务流程。
在SOA中，服务之间的通信基于标准协议（如HTTP、SOAP）和统一契约（如REST、WSDL），使得服务可以跨平台、语言和组织边界进行互操作。
这种架构方法的优点包括：
1. 灵活性：通过将应用程序拆分为独立的服务，企业可以更灵活地更改、替换或集成各个服务，而无需对整个应用程序进行重新构建。
2. 松耦合：SOA通过将服务封装在独立的组件中，实现了服务之间的松耦合。
这意味着服务之间的依赖关系最小化，有助于提高系统的可维护性和可扩展性。
3. 标准化：通过使用统一的接口规范和通信协议，SOA有助于实现服务的标准化和互操作性，从而提高企业应用的集成能力。
4. 复用性：SOA通过将功能封装为可重复使用的服务，提高了代码的复用性，减少了重复开发和资源浪费。
5. 降低成本：通过将应用程序拆分为多个小型服务，可以并行开发、测试和部署这些服务，从而加快开发周期并降低开发成本。
6. 分布式系统：SOA适用于分布式系统环境，支持异构系统的集成和交互，使得企业能够构建灵活、可扩展的大型应用系统。
总之，SOA是一种以服务为核心的软件架构方法，它通过将应用程序拆分为独立的服务，实现应用程序的模块化、标准化和灵活性。
这种架构方法有助于提高企业的软件应用能力和业务敏捷性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
不断涌现的新型业务
自相似性 突发性 流量不确定性 降低网络运维费用的
带宽按需分配（BoD)
虚拟专用网(OVPN) 光组播 光域区分服务质量 带宽/波长的批发
要求
ASON的优势集中表现在其组网应用的动态、灵活、高效和智能方 面。支持多粒度、多层次的智能，提供多样化、个性化的服务，是 ASON的核心特征。
ASON & GMPLS Architecture
Part A: ASON Architecture
自动交换光网络(ASON）
1. 2. 3. 4. 自动交换光网络的发展 自动交换光网络的体系结构 自动交换光网络的控制平面 自动交换光网络支持的新业务
自动交换光网络研究的必要性
IP业务特征：
三个平面间的接口
管理平面与控制平
面的接口(NMI-A)
管理平面与传送平
面的接口(NMI-T) 连接控制接口(CCI)
自动交换光网络的控制平面
1）控制平面的接口
UNI UNI 全局ASON 用户终端系统 用户终端系统
用户网络接口 (UNI) 外部网络网络 接口（E-NNI） 内部网络网络 接口（I-NNI）
OIF2002.378 ENNI 1.0层次路由
OIF2002.023 基于OSPF的层次 路由（DDRP）
OIF2002.163 基于ISIS的层次 路由
IETF GMPLS 建议框架
Signaling RFC 3471 (GMPLS) Signaling Functional Description RFC3472 (GMPLS) (CR-LDP) Extensions
OIF主 要界于 其它二 者之间 ，主要 解决 UNI和 NNI的 问题。
Charter: Evolution of the Internet (IP) Architecture
Membership: Individuals – community model
Charter: Development of Optical Networking Products and Services
GMPLS CR-LDP
G.7714.1
SDH/OTN的 自动发现协议
OIF建议框架
UNI需求 ENNI需求
OIF2000.155
OIF2002.229
OIF2000.125.07 UNI 1.0 OIF2003.248 UNI 1.0R2 OIF2003.293 UNI 2.0
OIF2003.179 ENNI 1.0信令规范
ASON的优势
显著降低网络整体运营成本(资源和拓扑的自动发现，灵活的
Mesh组网提高业务的生存性和网络的扩展性，多节点失效 情况下的业务恢复能力,更高的网络资源利用率 ）
具有扩展的信令集合，能实现快速业务提供和拓展 允许动态分配网络资源、提升网络节点业务处理能力、缩短业务 升级扩容时间 ； 非常易于引入光网络新业务，比如SLA按需、带宽业务、波长出 租、波长批发以及O-VPN等 。
Core Participants: • Global Service Providers, PTTs, ILECs • Telecom equipment vendors Goal: International Standards
作为唯一的全球电信 标准的权威制定组织 及坚定客户-服务模型 支持者的ITU-T，它 采用的是传统的从上 往下设计方法，主要 负责网络体系结构和 网络功能要求并已完 成一系列标准，网络 构建方式是采用重叠 模型
1. Neighbor Discovery
NETWORK MGMT PLANE
2. Global Topology Dissemination
User
OUNI
CONTROL PLANE
User
DATA PLANE
3. Connection Request 4. Path Calculation (NE-based or EMS-based)
Draft-IETF-CCAMP-LMP Link management Draft-IETF-CCAMPLMP-WDM
RFC3473 (GMPLS) (RSVP-TE) Extensions
Draft-IETF-CCAMPGMPLS-Architecture
GMPLS Framework
Draft-IETF-CCAMPGMPLS-Routing Routing Draft-IETF-CCAMPOSPF-GMPLSExtensions Draft-IETF-CCAMPGMPLS-SONET-SDH
CCI NMI
Switch Switch
管理平面
业务平面
Switch
控制平面是智能光网络体系与传统光网络体系的最大区别； ASON不是革命，是提高光网络效率、适应业务动态性的一种改进。
ASON的体系结构
三个平面
– 传送平面 (Transport Plane) – 控制平面(Control Plane) – 管理平面 (Management Plane)
SPC连接建立信令流程示意
管理平面
连接请求
控制平面
建立请求
建立请求
建立请求
连接终点
A
NE
NE 传送平面
NE
连接终点 B
永久连接
交换连接 软永久连接
永久连接
端到端混合连接
SC连接－交换连接 控制平面
连接请求 UNI 建立请求 建立请求 建立请求 连接请求 UNI
连接终点
A
NE
NE 传送平面 交换连接
ASON概述
何谓ASON？
ASON是能够智能化地、自动完成光网络交换连接功能的新一代光传送 网。所谓自动交换连接是指：在网络资源和拓扑结构的自动发现的基础上 ，调用动态智能选路算法，通过分布式信令处理和交互，建立端到端的按 需连接，同时提供可行可靠的保护恢复机制，实现故障情况下连接的自动 重构。
Inventory & Resource Management
No. of Members: 312 Principal Members
Core Participants: • ISPs, Carriers • Router/switch and SW Vendors Goal: Internet Evolution
Core Participants: • PTTs, ISPs, ILECs, IXCs • Optical Networking Vendors Goal: Optical Network Evolution
CCI£ º ¬ Á ½ Ó Ø ¿ Ö Æ Ó ½ ¿ Ú NMI: Í ø ç Â ¹ Ü í À ½ Ó Ú ¿
Å Á Ð î Ð Å Ï ¢ ´ « Ë Í
ý ¾ Ê Ý Í ¨Ð Å Í ø £ ¨ DCN)
OCC
OCC OCC OCC
NMI
控制平面
OCC
NMI 网络管理接口 CCI 连接控制接口 OCC 光连接控制 Switch Switch
业务链路通道
线路接口
业务交叉平面
线路接口
管理链路通道
业务链路通道
控制平面的结构组件
呼叫控制器 连接控制器 路由控制器 链路资源管 理器 协议控制器 流量策略 发现代理 终端适配组件
控制节点
呼叫控制器 （CallC）
流量策略 （TP）
路由控制器 （RC）
连接控制器 （CC）
Dynamic Provisioning
5. Establish Connection
ASON的特点
控制为主的工作方式：ASON的最大特点就是从传统的传 输节点设备和管理系统中抽象分离出了控制平面。 分布式智能：ASON的重要标志是实现了网络的分布式智 能，即网元的智能化，具体体现为依靠网元实现网络拓 扑发现、路由计算、链路自动配置、路径的管理和控制、 业务的保护和恢复等。 多层统一与协调：在ASON中网络层次细化，体现了多种 粒度，但多层的控制却是统一的，通过公共的控制平面 来协调各层的工作。 面向业务：ASON业务提供能力强大，业务种类丰富，能 在光层直接实现动态业务分配，不仅缩短了业务部署时 间，而且提高了网络资源的利用率。ASON支持客户与网 络间的服务水平协议（SLA），可根据业务需要提供带宽 和所需要的保护等级，是面向业务的网络。
ASON的标准化工作
三大标准化组织在ASON标准化过程中的不同态度：
Charter: Global Telecom Architecture and Standards
No. of Members: 189 Member States + 434 Sector Members
IETF则是更加侧重于 具体信令和路由协议 IETF扩展 GMPLS协 议。最初 基于对等 模型，但 现在覆盖 客户-服务 者关系， 但其基本 倾向仍然 是对等模 型
CP ÜÀ ¹ í TP ² ã Í ø Â ç ¹ Ü À í ×Ô Ê ´¹ Ü À í
Ø ¿ Ö Æ Æ ½ Ã æ £ ¨ CP)
CCI
LN1 LN2 LN3
Ü À ¹ í Æ ½ Ã æ £ ¨ MP)
NMI-T
Ü À ¹ í Ð Å Ï ¢ ´ « Ë Í
« ´ Ë Í Æ ½ Ã æ (TP)
ITU-T ASON建议框架
G.807
总体需求
G.8080
框架结构
G.7712
DCN
G.7713
呼叫连接管理
G.7714
自动发现
G.7715
路由需求
G.7716
链路管理