Unión Internacional de Telecomunicaciones

UIT-T G.7041/Y.1303
SECTOR DE NORMALIZACIÓN (08/2005)
DE LAS TELECOMUNICACIONES
DE LA UIT

SERIE G: SISTEMAS Y MEDIOS DE TRANSMISIÓN,

SISTEMAS Y REDES DIGITALES
Datos sobre capa de transporte – Aspectos genéricos –
Generalidades
SERIE Y: INFRAESTRUCTURA MUNDIAL DE LA
INFORMACIÓN, ASPECTOS DEL PROTOCOLO
INTERNET Y REDES DE LA PRÓXIMA GENERACIÓN
Aspectos del protocolo Internet – Transporte

Procedimiento de entramado genérico

Recomendación UIT-T G.7041/Y.1303

 RECOMENDACIONES UIT-T DE LA SERIE G
SISTEMAS Y MEDIOS DE TRANSMISIÓN, SISTEMAS Y REDES DIGITALES

CONEXIONES Y CIRCUITOS TELEFÓNICOS INTERNACIONALES G.100–G.199

CARACTERÍSTICAS GENERALES COMUNES A TODOS LOS SISTEMAS ANALÓGICOS G.200–G.299
DE PORTADORAS
CARACTERÍSTICAS INDIVIDUALES DE LOS SISTEMAS TELEFÓNICOS G.300–G.399
INTERNACIONALES DE PORTADORAS EN LÍNEAS METÁLICAS
CARACTERÍSTICAS GENERALES DE LOS SISTEMAS TELEFÓNICOS G.400–G.449
INTERNACIONALES EN RADIOENLACES O POR SATÉLITE E INTERCONEXIÓN CON
LOS SISTEMAS EN LÍNEAS METÁLICAS
COORDINACIÓN DE LA RADIOTELEFONÍA Y LA TELEFONÍA EN LÍNEA G.450–G.499
CARACTERÍSTICAS DE LOS MEDIOS DE TRANSMISIÓN G.600–G.699
EQUIPOS TERMINALES DIGITALES G.700–G.799
REDES DIGITALES G.800–G.899
SECCIONES DIGITALES Y SISTEMAS DIGITALES DE LÍNEA G.900–G.999
CALIDAD DE SERVICIO Y DE TRANSMISIÓN – ASPECTOS GENÉRICOS Y ASPECTOS G.1000–G.1999
RELACIONADOS AL USUARIO
CARACTERÍSTICAS DE LOS MEDIOS DE TRANSMISIÓN G.6000–G.6999
DATOS SOBRE CAPA DE TRANSPORTE – ASPECTOS GENÉRICOS G.7000–G.7999
Generalidades G.7000–G.7099
Aspectos del control de las redes de transporte G.7700–G.7799
ASPECTOS RELATIVOS AL PROTOCOLO ETHERNET SOBRE LA CAPA DE G.8000–G.8999
TRANSPORTE
REDES DE ACCESO G.9000–G.9999

Para más información, véase la Lista de Recomendaciones del UIT-T.

Recomendación UIT-T G.7041/Y.1303

Procedimiento de entramado genérico

Resumen
En esta Recomendación se define un procedimiento de entramado genérico (GFP) para delimitar la
cabida útil de la longitud variable y octetos alineados, de las señales cliente de nivel superior para su
posterior conversión en trayectos de octetos síncronos como los definidos en las
Recs. UIT-T G.707/Y.1322, G.8040/Y.1340 y G.709/Y.1331. Entre las definiciones de la
Recomendación se encuentran:
− las de los formatos de trama para las unidades de datos de protocolo (PDU) transferidas
entre los puntos GFP de inicio y terminación;
− la del procedimiento de conversión de las señales cliente en GFP.

Orígenes
La Recomendación UIT-T G.7041/Y.1303 fue aprobada el 22 de agosto de 2005 por la Comisión de
Estudio 15 (2005-2008) del UIT-T por el procedimiento de la Recomendación UIT-T A.8.

Palabras clave
Jerarquía digital síncrona, procedimiento de entramado genérico, red óptica de transporte.

Rec. UIT-T G.7041/Y.1303 (08/2005) i

 PREFACIO
La UIT (Unión Internacional de Telecomunicaciones) es el organismo especializado de las Naciones Unidas
en el campo de las telecomunicaciones. El UIT-T (Sector de Normalización de las Telecomunicaciones de la
UIT) es un órgano permanente de la UIT. Este órgano estudia los aspectos técnicos, de explotación y
tarifarios y publica Recomendaciones sobre los mismos, con miras a la normalización de las telecomunica-
ciones en el plano mundial.
La Asamblea Mundial de Normalización de las Telecomunicaciones (AMNT), que se celebra cada cuatro
años, establece los temas que han de estudiar las Comisiones de Estudio del UIT-T, que a su vez producen
Recomendaciones sobre dichos temas.
La aprobación de Recomendaciones por los Miembros del UIT-T es el objeto del procedimiento establecido
en la Resolución 1 de la AMNT.
En ciertos sectores de la tecnología de la información que corresponden a la esfera de competencia del
UIT-T, se preparan las normas necesarias en colaboración con la ISO y la CEI.

NOTA
En esta Recomendación, la expresión "Administración" se utiliza para designar, en forma abreviada, tanto
una administración de telecomunicaciones como una empresa de explotación reconocida de
telecomunicaciones.
La observancia de esta Recomendación es voluntaria. Ahora bien, la Recomendación puede contener ciertas
disposiciones obligatorias (para asegurar, por ejemplo, la aplicabilidad o la interoperabilidad), por lo que la
observancia se consigue con el cumplimiento exacto y puntual de todas las disposiciones obligatorias. La
obligatoriedad de un elemento preceptivo o requisito se expresa mediante las frases "tener que, haber de, hay
que + infinitivo" o el verbo principal en tiempo futuro simple de mandato, en modo afirmativo o negativo. El
hecho de que se utilice esta formulación no entraña que la observancia se imponga a ninguna de las partes.

PROPIEDAD INTELECTUAL
La UIT señala a la atención la posibilidad de que la utilización o aplicación de la presente Recomendación
suponga el empleo de un derecho de propiedad intelectual reivindicado. La UIT no adopta ninguna posición
en cuanto a la demostración, validez o aplicabilidad de los derechos de propiedad intelectual reivindicados,
ya sea por los miembros de la UIT o por terceros ajenos al proceso de elaboración de Recomendaciones.
En la fecha de aprobación de la presente Recomendación, la UIT ha recibido notificación de propiedad
intelectual, protegida por patente, que puede ser necesaria para aplicar esta Recomendación. Sin embargo,
debe señalarse a los usuarios que puede que esta información no se encuentre totalmente actualizada al
respecto, por lo que se les insta encarecidamente a consultar la base de datos sobre patentes de la TSB.

 UIT 2006
Reservados todos los derechos. Ninguna parte de esta publicación puede reproducirse por ningún
procedimiento sin previa autorización escrita por parte de la UIT.

ii Rec. UIT-T G.7041/Y.1303 (08/2005)

 ÍNDICE
Página
1 Alcance ......................................................................................................................... 1
2 Referencias ................................................................................................................... 1
3 Términos y definiciones ............................................................................................... 3
4 Abreviaturas, siglas o acrónimos.................................................................................. 4
5 Convenios ..................................................................................................................... 6
6 Aspectos del GFP comunes a la correspondencia de tramas y a la correspondencia
transparente................................................................................................................... 6
6.1 Estructura de señal básica para las tramas cliente GFP.................................. 6
6.2 Tramas de control GFP................................................................................... 18
6.3 Funciones a nivel de trama GFP..................................................................... 19
7 Aspectos específicos de cabida útil para GFP con correspondencia de trama ............. 22
7.1 Cabida útil de MAC de Ethernet .................................................................... 22
7.2 Cabida útil HDLC/PPP................................................................................... 23
7.3 Cabida útil de canal para fibra a través de FC-BBW_SONET ...................... 24
7.4 Tratamiento de errores en GFP con correspondencia de trama...................... 25
7.5 Cabida útil RPR IEEE 802.17 ........................................................................ 26
7.6 Conversión directa de tramas MPLS en tramas GFP-F.................................. 26
7.7 Conversión directa de las PDU IP e IS-IS en tramas GFP-F ......................... 27
7.8 Cabida útil de la DVB ASI............................................................................. 27
8 Aspectos específicos de la cabida útil para la conversión transparente de
clientes 8B/10B a GFP ................................................................................................. 30
8.1 Aspectos comunes de GFP-T ......................................................................... 30
8.2 Disparidad de funcionamiento en los códigos 64B/65B ................................ 35
8.3 Aspectos de fallo de la señal específicos del cliente ...................................... 37
8.4 Conversión transparente a máxima velocidad síncrona de clientes 8B/10B
en GFP ............................................................................................................ 40
8.5 Conversión asíncrona (a velocidad máxima o a una velocidad inferior) de
clientes 8B/10B en GFP ................................................................................. 44
Apéndice I – Ejemplos de modelos funcionales de aplicaciones GFP .................................... 45
Apéndice II – Ejemplos de tipos de cabida útil GFP ............................................................... 48
Apéndice III – Ejemplo de trama GFP que ilustra el orden de transmisión y el cálculo
de CRC ......................................................................................................................... 49
III.1 Ejemplo práctico de trama GFP-F.................................................................. 49
III.2 Ejemplo examinado del cálculo de la CRC de un superbloque GFP-T ......... 52

Rec. UIT-T G.7041/Y.1303 (08/2005) iii

 Página
Apéndice IV – Número de superbloques utilizados en el GFP transparente ........................... 53
IV.1 Introducción.................................................................................................... 53
IV.2 Cálculo de la anchura de banda "de reserva" ................................................. 53
IV.3 Cálculo de la anchura de banda disponible para las CMF.............................. 54
Apéndice V – Requisitos de anchura de banda para el transporte Ethernet ............................ 56

iv Rec. UIT-T G.7041/Y.1303 (08/2005)

Introducción
El procedimiento de entramado genérico (GFP) proporciona un mecanismo genérico para adaptar el
tráfico de señales cliente de nivel superior por una red de transporte. Las señales cliente pueden
estar constituidas por unidades de datos de protocolo (PDU) (por ejemplo IP/PPP o Ethernet MAC),
o ser un tren de velocidad binaria constante con código de bloque (por ejemplo las de los canales de
fibra o las ESCON/SBCON).
La especificación del GFP consta de aspectos comunes y aspectos específicos del cliente. Los
aspectos comunes del GFP son válidos para todo tráfico adaptado a GFP, y se especifican en la
cláusula 6. Los aspectos del GFP que son propios del cliente se especifican en las cláusulas 7 y 8.
Actualmente hay dos modos de adaptación de la señal cliente definidos para GFP.
• Un modo de adaptación con PDU, conocido como GFP con correspondencia de trama
(GFP-F, frame-mapped GFP), especificado en la cláusula 7.
• Un modo de adaptación con código de bloque, conocido como GFP transparente (GFP-T),
especificado en la cláusula 8.
En la figura 1 se representa la relación entre las señales cliente de capa superior, el GFP y sus
trayectos de transporte.

Figura 1/G.7041/Y.1303 − Relación del GFP con las señales

cliente y los trayectos de transporte

En la figura 2 se representa el entorno en que funciona el GFP.

Figura 2/G.7041/Y.1303 − Modelo funcional del GFP (un solo cliente)

Rec. UIT-T G.7041/Y.1303 (08/2005) v

En el modo de adaptación orientado a correspondencia de tramas, la función de adaptación
cliente/GFP puede funcionar en la capa de enlace de datos (o en una capa superior) de la señal
cliente. Se requiere la visibilidad de la PDU cliente. Esta visibilidad se obtiene cuando las PDU
cliente se reciben, ya sea de la red de capa de datos [por ejemplo, textura de encaminador IP o
textura de conmutador Ethernet (C/C' en la figura 2)] o, por ejemplo, de una función puente,
conmutador o encaminador en un elemento de red de transporte (TNE, transport network element).
En este último caso, las PDU cliente se reciben, por ejemplo, a través de una interfaz Ethernet (A/A'
en la figura 2).
En el modo de adaptación transparente, la función de adaptación cliente/GFP actúa sobre el tren de
caracteres codificados, y no sobre las PDU cliente entrantes. Por tanto, se requiere el tratamiento del
espacio de palabra código entrante para la señal cliente (B/B' en la figura 2).
Generalmente es posible establecer interconexiones entre los puertos A y A', B y B', C y C', A y C'
y C y A'. Téngase presente que el tipo de puerto físico para B y B' debe ser el mismo para poder
establecer una interconexión, mientras que el tipo de puerto físico de A y A' puede ser diferente.
En el apéndice I se presentan algunos modelos funcionales de alto nivel asociados con el
tratamiento GFP antes mencionado.

vi Rec. UIT-T G.7041/Y.1303 (08/2005)

Recomendación UIT-T G.7041/Y.1303

Procedimiento de entramado genérico

1 Alcance
En esta Recomendación se define un procedimiento de entramado genérico (GFP, generic framing
procedure) para encapsular la cabida útil de longitud variable de diversas señales cliente, a fin de
transportarlas posteriormente por redes SDH, PDH u OTN, como se define en las
Recs. UIT-T G.707/Y.1322, G.8040/Y.1340 y G.709/Y.1331. En esta Recomendación se definen:
− los formatos de trama para unidades de datos de protocolo (PDU, protocol data unit)
transferidas entre los puntos GFP de inicio y de terminación;
− el procedimiento de conversión de las señales cliente en GFP.
El procedimiento de entramado descrito en esta Recomendación se puede aplicar tanto al
encapsulado de tramas cliente completas (GFP con correspondencia de trama), en el que una trama
cliente se convierte en una trama GFP, como al transporte con conversión de caracteres (GFP
transparente), en el que varios caracteres de datos cliente se convierten en códigos de bloque
eficientes para su transporte dentro de una trama GFP.

2 Referencias
Las siguientes Recomendaciones del UIT-T y otras referencias contienen disposiciones que,
mediante su referencia en este texto, constituyen disposiciones de la presente Recomendación. Al
efectuar esta publicación, estaban en vigor las ediciones indicadas. Todas las Recomendaciones y
otras referencias son objeto de revisiones por lo que se preconiza que los usuarios de esta
Recomendación investiguen la posibilidad de aplicar las ediciones más recientes de las
Recomendaciones y otras referencias citadas a continuación. Se publica periódicamente una lista de
las Recomendaciones UIT-T actualmente vigentes. En esta Recomendación, la referencia a un
documento, en tanto que autónomo, no le otorga el rango de una Recomendación.
− Recomendación UIT-T G.707/Y.1322 (2003), Interfaz de nodo de red para la jerarquía
digital síncrona.
− Recomendación UIT-T G.709/Y.1331 (2003), Interfaces para la red óptica de
transporte.
− Recomendación UIT-T G.783 (2004), Características de los bloques funcionales del
equipo de la jerarquía digital síncrona.
− Recomendación UIT-T G.798 (2004), Características de los bloques funcionales del
equipo de la jerarquía de la red óptica de transporte.
− Recomendación UIT-T G.806 (2004), Características del equipo de transporte –
Metodología de descripción y funcionalidad genérica.
– Recomendación UIT-T G.8021/Y.1341 (2004), Características de los bloques funcionales
de equipos de red de transporte Ethernet.
– Recomendación UIT-T G.8040/Y.1340 (2005), Correspondencia de tramas de
procedimiento de entramado genérico en jerarquía digital plesiócrona.
– Recomendación UIT-T H.222.0 (2000), Tecnología de la información – Codificación
genérica de imágenes en movimiento e información de audio asociada: Sistemas.

Rec. UIT-T G.7041/Y.1303 (08/2005) 1

− Recomendación UIT-T I.432.1 (1999), Interfaz usuario-red de la red digital de servicios
integrados de banda ancha (RDSI-BA) – Especificación de la capa física: Características
generales.
– Recomendación UIT-T J.131 (1998), Transporte de señales MPEG-2 en redes con
jerarquía digital plesiócrona.
– Recomendación UIT-T J.132 (1998), Transporte de señales MPEG-2 en redes de la
jerarquía digital síncrona.
– Recomendación UIT-T J.133 (2002), Mediciones de trenes de transporte MPEG-2 en las
redes.
− IEEE 802.3-2002, Information Technology – Telecommunications and Information
Exchange Between Systems – LAN/MAN – Specific Requirements – Part 3: Carrier Sense
Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer
Specifications.
– IEEE 802.17-2004, Information technology – Telecommunications and information
exchange between systems – Local and metropolitan area networks – Specific
requirements – Part 17: Resilient packet ring (RPR) access method & physical layer
specifications.
− ANSI INCITS 230-1994, Information Technology – Fibre Channel – Physical and
Signaling Interface (FC-PH).
– ANSI INCITS 296-1997, Information Technology – Single-Byte Command Code Sets
CONnection (SBCON) Architecture.
– ANSI INCITS 342-2001, Information Technology – Fibre Channel Backbone (FC-BB).
– ANSI INCITS 372-2003, Information Technology – Fibre Channel Backbone (FC-BB-2).
– ETSI (CENELEC) EN 50083-9:2002, Cable networks for television signals, sound signals
and interactive services; Part 9: Interfaces for CATV/SMATV headends and similar
professional equipment for DVB/MPEG-2 transport streams. (DVB Blue Book A010),
Annex B, Asynchronous Serial Interface.
– ETSI TR 101 891 (2001), Digital Video Broadcasting (DVB); Professional Interfaces:
Guidelines for the implementation and usage of the DVB Asynchronous Serial Interface
(ASI).
– ETSI TR 101 290 (2001), Digital Video Broadcasting (DVB); Measurement guidelines for
DVB systems.
– ETSI ETS 300 813 (1997), Digital Video Broadcasting (DVB); DVB interfaces to
Plesiochronous Digital Hierarchy (PDH) networks.
– ETSI ETS 300 814 (1998), Digital Video Broadcasting (DVB); DVB interfaces to
Synchronous Digital Hierarchy (SDH) networks.
– IETF RFC 791/STD0005 (1981), Internet Protocol.
– IETF RFC 1195 (1990), Use of OSI IS-IS for Routing in TCP/IP and Dual Environments.
– IETF RFC 1661 (1994), The Point-to-Point Protocol (PPP).
– IETF RFC 1662 (1994), PPP in HDLC-like Framing.
– IETF RFC 2460 (1998), Internet Protocol, Version 6 (IPv6) Specification.
– IETF RFC 3032 (2001), MPLS Label Stack Encoding.

2 Rec. UIT-T G.7041/Y.1303 (08/2005)

– ISO/CEI 10589:2002, Information technology – Telecommunications and information
exchange between systems – Intermediate System to intermediate system intra-domain
routeing information exchange protocol for use in conjunction with the protocol for
providing the connectionless-mode network service (ISO 8473).
– ISO/CEI 13239:2002, Information technology – Telecommunications and information
exchange between systems – High-level Data Link Control (HDLC) procedures.
– ISO/CEI 13818-1:2000, Information technology – Generic coding of moving pictures and
associated audio information: Systems.
– ISO/CEI 13818-9:1996, Information technology – Generic coding of moving pictures and
associated audio information – Part 9: Extension for real time interface for systems
decoders.

3 Términos y definiciones
En esta Recomendación se definen los términos siguientes.
3.1 procedimiento de entramado genérico con correspondencia de trama: Tipo de
correspondencia GFP en el cual la trama de señal cliente recibida se hace corresponder enteramente
a una trama GFP.
3.2 identificador de canal (CID, channel ID): Número binario de 8 bits que se utiliza para
indicar uno de los 256 canales de comunicación en un punto de iniciación/terminación GFP.
3.3 trama de datos cliente: Trama GFP que contiene datos de cabida útil procedentes de una
señal cliente.
3.4 trama de gestión cliente: Trama GFP que contiene información relativa a la gestión de la
conexión GFP entre la fuente y el sumidero GFP.
3.5 trama de control: Trama GFP que se utiliza para controlar la conexión GFP. El único
control definido hasta ahora es la trama Reposo.
3.6 unidad de transmisión máxima (MTU, maximum transmission unit): Tamaño máximo
de la cabida útil GFP, en octetos.
3.7 disparidad de funcionamiento: Procedimiento utilizado por los códigos de línea en
bloque, por ejemplo 8B/10B, para equilibrar el número total de unos y ceros transmitidos en un
periodo de tiempo. La disparidad de funcionamiento al final de un subbloque de código de línea es
positiva si se han enviado más unos que ceros hasta ese punto, y negativa si se han enviado más
ceros que unos. El codificador utiliza el valor de disparidad de funcionamiento para determinar cuál
de los dos códigos posibles se utilizará para transmitir en la siguiente conversión de carácter, a fin
de equilibrar el número de unos y ceros transmitidos.
3.8 puerto de fuente/destino (SP/DP, source port/destination port): Entidad lógica
direccionable en una interfaz física.
3.9 superbloque: Estructura GFP transparente que combina múltiples códigos 64B/65B junto
con una CRC-16, para conseguir la alineación de los octetos de la cabida útil y el control de errores
en los bits del superbloque. Véase la figura 8-3.
3.10 procedimiento de entramado genérico transparente: Tipo de correspondencia GFP en la
cual se decodifican caracteres cliente codificados en bloques, que se convierten a una trama GFP de
longitud fija, y pueden transmitirse inmediatamente sin esperar la recepción de toda la trama de
datos cliente.

Rec. UIT-T G.7041/Y.1303 (08/2005) 3

4 Abreviaturas, siglas o acrónimos
En esta Recomendación se utilizan las siguientes abreviaturas, siglas o acrónimos.
ANSI Instituto nacional de normas de los Estados Unidos (American National Standards
Institute)
ASI Interfaz asíncrona para DVB (asynchronous interface for DVB)
ATM Modo de transferencia asíncrono (asynchronous transfer mode)
cHEC HEC principal, HEC de núcleo (core HEC)
CID ID de canal (channel ID)
CoS Clase de servicio (class of service)
CRC Verificación por redundancia cíclica (cyclic redundancy check)
CSF Fallo de señal cliente (client signal fail)
DE Elegibilidad de descarte (discard eligibility)
DP Puerto de destino (destination port)
DST Destino (destination)
DVB Difusión de vídeo digital (digital video broadcast)
eHEC HEC de extensión (extension HEC)
EOF Fin de trama (end of frame)
ESCON Conexión de sistemas de empresa (enterprise systems connection)
EXI Identificador de encabezamiento de extensión (extension header identifier)
FC Canal para fibra (fibre channel)
FCS Secuencia de verificación de trama (frame check sequence)
FICON Conexión para fibra (fibre connection)
GFP Procedimiento de entramado genérico (generic framing procedure)
GFP-F GFP con correspondencia de trama (frame mapped GFP)
GFP-T GFP transparente (transparent GFP)
HDLC Control de alto nivel para enlace de datos (high-level data link control)
HEC Control de errores del encabezamiento (header error check)
IEEE Institute of Electrical and Electronic Engineers
IFG Intervalo entre tramas (inter-frame gap)
IP Protocolo Internet (Internet protocol)
IPG Intervalo interpaquete (inter-packet gap)
ISO Organización Internacional de Normalización (International Organization for
Standardization)
LCC Último carácter de control (last control character)
LOL Pérdida de luz (loss of light)
LOS Pérdida de señal (loss of signal)
LSB Bit menos significativo (least significant bit)

4 Rec. UIT-T G.7041/Y.1303 (08/2005)

MAC Control de acceso a medios (media access control)
MAPOS Protocolo de acceso múltiple sobre SONET/SDH (multiple access protocol over
SONET/SDH)
MPEG Grupo de expertos en imágenes en movimiento (moving picture expert group)
MPLS Conmutación por etiquetas multiprotocolo (multiprotocol label switching)
MSB Bit más significativo (most significant bit)
MTU Unidad de transmisión máxima (maximum transmission unit)
NE Elemento de red (network element)
OAM Operaciones, administración y mantenimiento
ODU Unidad de datos óptica (optical data unit)
OTN Red óptica de transporte (optical transport network)
PCR Referencia de reloj de programa (program clock reference)
PDH Jerarquía digital plesiócrona (plesiochronous digital hierarchy)
PDU Unidad de datos de protocolo (protocol data unit)
PFI Identificador de FCS de cabida útil (payload FCS indicator)
PLI Indicador de longitud de cabida útil (payload length indicator)
PPP Protocolo punto a punto (point-to-point protocol)
PTI Identificador de tipo de la cabida útil (payload type identifier)
RD Disparidad de funcionamiento (running disparity)
RDSI Red digital de servicios integrados
RPR Anillo de paquetes resistente (resilient packet ring)
RS Reed-Solomon
SBCON Conexión por conjuntos de códigos de instrucción de un solo octeto (single-byte
command code sets connection)
SDH Jerarquía digital síncrona (synchronous digital hierarchy)
SDTV Televisión de definición normalizada (standard definition TV)
SOF Comienzo de trama (start of frame)
SONET Red óptica síncrona (synchronous optical network)
SP Puerto fuente (source port)
SPE Envolvente de cabida útil síncrona (synchronous payload envelope)
SRC Fuente (source)
SSF Fallo de señal de servidor (server signal failure)
STS Señal de transporte síncrona (synchronous transport signal)
tHEC HEC de tipo (type HEC)
TS Tren de transporte (transport stream)
TSF Fallo de señal de camino (trail signal fail)
TTL Tiempo de vida (time-to-live)

Rec. UIT-T G.7041/Y.1303 (08/2005) 5

UIT-T Unión Internacional de Telecomunicaciones – Sector de Normalización de las
Telecomunicaciones
UPI Identificador de cabida útil de usuario (user payload identifier)

5 Convenios
Orden de transmisión: El orden de transmisión de información en todos los diagramas de la
presente Recomendación es, primero, de izquierda a derecha y después de arriba a abajo. En cada
octeto, se transmite primero el bit más significativo. El bit más significativo aparece a la izquierda
en todos los diagramas.
Valores de campo no definidos: El valor por defecto de todos los campos de encabezamiento
definidos es 0, a menos que se indique otra cosa.

6 Aspectos del GFP comunes a la correspondencia de tramas y a la correspondencia

transparente
En esta cláusula se describen los aspectos comunes (independientes del protocolo) del GFP para la
cabida útil de octetos alineados. La conversión de las cabidas útiles entramadas en un VC-n SDH se
especifica en la Rec. UIT-T G.707/Y.1322. La conversión de las cabidas útiles entramadas en una
cabida útil OTN ODUk se especifica en la Rec. UIT-T G.709/Y.1331.
El GFP utiliza una variante del mecanismo de delimitación de trama basado en HEC definido para
el modo de transferencia asíncrono (ATM, asynchronous transfer mode) (véase la
Rec. UIT-T I.432.1). Se definen dos tipos de tramas GFP: tramas cliente GFP y tramas de control
GFP. Los formatos de las tramas cliente GFP y de las tramas de control GFP se definen en 6.1 y
6.2. El GFP también soporta un mecanismo de extensión de encabezamiento (de cabida útil)
flexible que facilita la adaptación del GFP para su utilización con diversos mecanismos de
transporte. Los tipos de encabezamiento de extensión de cabida útil actualmente definidos se
especifican en 6.1.2.3.

6.1 Estructura de señal básica para las tramas cliente GFP

El formato de las tramas GFP se muestra en la figura 6-1. Las tramas GFP están alineadas en
octetos y constan de un encabezamiento principal GFP y, salvo para las tramas Reposo GFP, un
área de cabida útil GFP.

6 Rec. UIT-T G.7041/Y.1303 (08/2005)

 Figura 6-1/G.7041/Y.1303 − Formato de la trama cliente GFP

6.1.1 Encabezamiento principal GFP

El formato del encabezamiento principal GFP se muestra en la figura 6-2. Los cuatro octetos del
encabezamiento principal GFP constan de un campo indicador de la longitud de cabida útil, de
16 bits, y un campo control de errores de encabezamiento principal (cHEC), de 16 bits. Este
encabezamiento permite que la alineación de la trama GFP sea independiente del contenido de las
PDU de capa superior.

Rec. UIT-T G.7041/Y.1303 (08/2005) 7

 Orden de transmisión de los octetos

1 PLI

2 PLI

3 cHEC

4 cHEC

1 2 3 4 5 6 7 8 Orden de transmisión de los bits

Figura 6-2/G.7041/Y.1303 – Formato del encabezamiento principal GFP

6.1.1.1 Campo indicador de la longitud de cabida útil (PLI)

El campo PLI de dos octetos contiene un número binario que representa el número de octetos del
áreas de cabida útil GFP. El valor mínimo absoluto del campo PLI de una trama cliente GFP es
de 4 octetos. Los valores 0-3 del PLI están reservados para uso de la trama de control GFP (véase
6.2).
6.1.1.2 Campo HEC principal (cHEC)
El campo control de errores de encabezamiento principal de dos octetos contiene un código de
control de errores CRC-16 que protege la integridad del contenido del encabezamiento principal,
permitiendo tanto la corrección de errores en un solo bit como la detección de errores en varios bits.
La secuencia cHEC se calcula sobre los octetos del encabezamiento principal como se indica
en 6.1.1.2.1.
6.1.1.2.1 Tratamiento del HEC
El polinomio generador de HEC es G(x) = x16 + x12 + x5 + 1, con un valor de inicialización de 0,
donde x16 corresponde al bit más significativo (MSB, most significant bit) y x0 corresponde al bit
menos significativo (LSB, least significant bit).
El campo cHEC es generado por el proceso de adaptación de fuente, en el que se siguen estos pasos
(véase el apéndice I/V.41):
1) Los dos primeros octetos de la trama GFP se toman en el orden en que se transmiten los
octetos en la red, empezando por el bit más significativo, para formar un esquema
de 16 bits que representa los coeficientes de un polinomio M(x) de grado 15.
2) M(x) se multiplica por x16 y se divide (módulo 2) por G(x), lo que da un residuo R(x) de
grado 15 o inferior.
3) Se considera que los coeficientes de R(x) son una secuencia de 16 bits, donde x15 es el bit
más significativo.
4) Esta secuencia de 16 bits es la CRC-16, donde el primer bit de la CRC-16 que habrá de
transmitirse es el coeficiente de x15 y el último bit es el coeficiente de x0.
En el proceso de adaptación del sumidero se siguen los pasos 1 a 3, tal como se hace en el proceso
de adaptación de la fuente. Cuando no hay errores en los bits, el residuo será 0000 0000 0000 0000.
Esta corrección de un solo bit se efectúa en el encabezamiento principal. El proceso de adaptación
del sumidero GFP descartará las tramas GFP en las que se detecten errores en varios bits. El
proceso de adaptación del sumidero también actualiza todos los registros de sistema pertinentes
para fines de supervisión de la calidad de funcionamiento.

8 Rec. UIT-T G.7041/Y.1303 (08/2005)

6.1.1.3 Aleatorización del encabezamiento principal
El encabezamiento principal se aleatoriza para mantener un equilibrio en corriente continua
mediante una operación "O" exclusiva (suma módulo 2) con el número hexadecimal B6AB31E0.
Este número es la secuencia de tipo Barker de transición máxima, lóbulo lateral mínimo, con una
longitud de 32. La aleatorización del encabezamiento principal GFP mejora la robustez del
procedimiento de delimitación de trama GFP y proporciona un número suficiente de
transiciones 0-1 y 1-0 durante los periodos de reposo sin transmisión.
6.1.2 Área de cabida útil GFP
El área de cabida útil GFP, integrada por todos los octetos de la trama GFP que se encuentran
después del encabezamiento principal GFP, se utiliza para transportar información de protocolo
específica de capa superior. En esta zona de longitud variable puede haber de 4 a 65 535 octetos.
Como puede verse en la figura 6-3, la cabida útil GFP consta de dos componentes comunes: un
encabezamiento de cabida útil y un campo de información de cabida útil. También puede haber un
campo FCS de cabida útil (pFCS, FCS payload) opcional.

Figura 6-3/G.7041/Y.1303 – Formato del área de cabida útil GFP

Los tamaños de la MTU GFP, en la práctica, para el área de cabida útil GFP, son específicos de la
aplicación. Una implementación debe soportar la transmisión y recepción de tramas GFP áreas de
cabida útil GFP de 1600 octetos como mínimo. Puede establecerse un acuerdo previo de manera
que las implementaciones GFP que lo acepten puedan utilizar otros valores de MTU. Las
implementaciones que soporten el canal para fibra con correspondencia de trama, también deben
soportar áreas de cabida útil GFP de al menos 2156 octetos.
6.1.2.1 Encabezamiento de cabida útil
El encabezamiento de cabida útil es una zona de longitud variable, de 4 a 64 octetos de longitud,
destinada a soportar procedimientos de gestión del enlace de datos específicos de la señal cliente de
capa superior. En la figura 6-4 se representa la estructura del encabezamiento de cabida útil
GFP. En esta zona hay dos campos obligatorios, los campos Tipo y tHEC, así como un número
variable de campos adicionales de encabezamiento de cabida útil. Este grupo de campos adicionales
de encabezamiento de cabida útil también se conoce como encabezamiento de extensión. El campo
Tipo especifica la presencia de un encabezamiento de extensión y su formato, así como la presencia
de la FCS opcional de cabida útil. El campo tHEC protege la integridad del campo Tipo.

Rec. UIT-T G.7041/Y.1303 (08/2005) 9

 Figura 6-4/G.7041/Y.1303 – Formato del encabezamiento de cabida útil GFP

Las implementaciones deberán soportar la recepción de tramas GFP con encabezamiento de cabida
útil de cualquier longitud entre 4 y 64 octetos.
6.1.2.1.1 Campo Tipo GFP
El campo Tipo GFP es un campo obligatorio de dos octetos del encabezamiento de cabida útil, que
indica el contenido y el formato del campo de información de cabida útil GFP (véase 6.1.2.2). El
campo Tipo distingue entre tipos de trama GFP y entre diferentes servicios en un entorno
multiservicios. Como puede verse en la figura 6-5, el campo Tipo está formado por un identificador
de tipo de cabida útil (PTI, payload type identifier), un identificador de FCS de cabida útil (PFI,
payload FCS indicator), un indicador de encabezamiento de extensión (EXI, extension header
identifier) y un identificador de cabida útil de usuario (UPI, user payload identifier).

Figura 6-5/G.7041/Y.1303 – Formato del campo Tipo GFP

La interpretación del campo UPI para valores del PTI diferentes de 000 ó 100 quedan en estudio. En
el apéndice II pueden verse ejemplos de valores del campo Tipo.
6.1.2.1.1.1 Identificador de tipo de cabida útil
Es un subcampo de 3 bits del campo Tipo que identifica el tipo de trama cliente GFP. Actualmente
están definidas dos clases de tramas cliente: tramas de datos de usuario (PTI = 000) y tramas de
gestión de cliente (PTI = 100). En el cuadro 6-1 se indican los puntos de código del PTI.

Cuadro 6-1/G.7041/Y.1303 − Identificadores del tipo de cabida útil GFP

Bits de Tipo <15:13> Utilización
000 Datos cliente
100 Gestión cliente
Otros Reservados

10 Rec. UIT-T G.7041/Y.1303 (08/2005)

6.1.2.1.1.2 Indicador de FCS de cabida útil (PFI)
Es un subcampo de un bit del campo Tipo, que indica la presencia (PFI = 1) o ausencia (PFI = 0)
del campo FCS de cabida útil.
6.1.2.1.1.3 Identificador de encabezamiento de extensión (EXI)
Es un subcampo de 4 bits del campo Tipo, que identifica el tipo de encabezamiento de extensión
GFP. Actualmente están definidas tres clases de encabezamiento de extensión: Un encabezamiento
de extensión nulo, un encabezamiento de extensión lineal y el encabezamiento de extensión en
anillo. En el cuadro 6-2 se indican los puntos de código del EXI.

Cuadro 6-2/G.7041/Y.1303 – Identificadores

de encabezamiento de extensión GFP
Bits de Tipo <11:8> Utilización
0000 Encabezamiento de extensión nulo
0001 Trama lineal
0010 Trama en anillo
Otros Reservados

6.1.2.1.1.4 Identificador de cabida útil de usuario (UPI)

Es un campo de 8 bits que identifica el tipo de cabida útil transportada en el campo Información de
cabida útil GFP. La interpretación del campo UPI está relacionada con el tipo de trama cliente GFP
indicada por el subcampo PTI. Los valores del UPI para tramas de datos cliente se especifican
en 6.1.3.1 y los valores del UPI para tramas de gestión cliente se especifican en 6.1.3.2.
6.1.2.1.2 Campo HEC de Tipo (tHEC)
El campo Control de errores de encabezamiento de tipo, de dos octetos, contiene un código de
control de error CRC-16 que protege la integridad del contenido del campo Tipo, permitiendo la
corrección de errores en un solo bit y la detección de errores en varios bits. El encabezamiento Tipo
consta del campo Tipo y del tHEC.
El contenido del campo tHEC se genera siguiendo los mismos pasos que para el cHEC
(véase 6.1.1.2.1) con la siguiente excepción:
− Para el tHEC, el paso 1 se modifica de manera que M(x) esté formado por todos los octetos
del campo Tipo, pero excluyendo el campo tHEC propiamente dicho.
El proceso de adaptación de sumidero GFP realizará la corrección de errores de un solo bit en el
campo Tipo, que está protegido por un campo tHEC. El proceso de adaptación de sumidero GFP
descartará todas las tramas GFP en que se detecten errores en varios bits. El proceso de adaptación
de sumidero también actualiza los registros de sistema pertinentes para fines de supervisión de la
calidad de funcionamiento.
6.1.2.1.3 Encabezamientos de extensión GFP
El encabezamiento de extensión de cabida útil es un campo extendido de 0 a 60 octetos (incluido el
eHEC) que soporta encabezamientos de enlace de datos que son propios de cada tecnología, tales
como identificadores de enlace virtual, direcciones de fuente/destino, números de puerto, clases de
servicio, control de errores del encabezamiento de extensión, etc. El tipo de encabezamiento de
extensión está indicado por el contenido de los bits EXI del campo Tipo del encabezamiento de
cabida útil.

Rec. UIT-T G.7041/Y.1303 (08/2005) 11

Actualmente están definidas tres variantes de encabezamiento de extensión para soportar datos
clientes específicos en configuraciones lógicas en anillo o configuraciones lógicas punto a punto
(lineales).
En esta subcláusula se describen los diversos campos de cada encabezamiento de extensión. El
valor por defecto de todo campo no definido es 0 a menos que se indique otra cosa.
6.1.2.1.3.1 Encabezamiento de extensión nulo
En la figura 6-6 se muestra el encabezamiento de cabida útil para una trama con un encabezamiento
de extensión nulo. Este encabezamiento de extensión corresponde a una configuración lógica punto
a punto. Está destinado a los casos en que el trayecto de transporte está dedicado a una señal cliente.

Figura 6-6/G.7041/Y.1303 – Encabezamiento de cabida útil

para una trama GFP con un encabezamiento
de extensión nulo

6.1.2.1.3.2 Encabezamiento de extensión de una trama lineal

El encabezamiento de cabida útil de una trama lineal (punto a punto) con un encabezamiento de
extensión, que se representa en la figura 6-7, está destinado a los casos en que hay varios enlaces
independientes que es necesario reunir en un solo trayecto de transporte.

Figura 6-7/G.7041/Y.1303 – Encabezamiento de cabida útil

de una trama lineal (punto a punto) que incluye
el encabezamiento de extensión

12 Rec. UIT-T G.7041/Y.1303 (08/2005)

6.1.2.1.3.2.1 Campo identificador de canal (CID)
El CID es un número binario de 8 bits utilizado para indicar uno de los 256 canales de
comunicación en un punto de terminación GFP.
6.1.2.1.3.2.2 Campo de reserva
El campo de reserva de 8 bits está reservado para utilización futura.
6.1.2.1.3.2.3 Campo HEC de extensión (eHEC)
Véase 6.1.2.1.4.
6.1.2.1.3.3 Encabezamiento de extensión para una trama en anillo
Queda en estudio.
6.1.2.1.4 Campo HEC de extensión (eHEC)
El campo control de errores del encabezamiento de extensión, de dos octetos, contiene un código de
control de errores CRC-16 que protege la integridad del contenido de los encabezamientos de
extensión, permitiendo la corrección de errores en un solo bit (facultativa) y la detección de errores
en varios bits.
El contenido del campo eHEC se genera siguiendo los mismos pasos que para el cHEC
(véase 6.1.1.2.1), con la siguiente excepción:
− Para el eHEC, el paso 1 se modifica de manera que M(x) esté formado por todos los octetos
del encabezamiento de extensión, excluyendo el campo eHEC propiamente dicho.
El proceso de adaptación del sumidero GFP puede corregir errores de un solo bit en todos los
campos protegidos por un campo tHEC. La corrección de errores de un solo bit es opcional para el
encabezamiento de extensión. El proceso de adaptación del sumidero GFP descartará todas las
tramas GFP en las que se detecten errores en varios bits, o en las que se produzca un error en un
campo de encabezamiento al que no se aplica la corrección de errores de un solo bit. El proceso de
adaptación del sumidero también actualiza todos los registros de sistema pertinentes para fines de
supervisión de la calidad de funcionamiento.
6.1.2.2 Campo información de cabida útil
El campo información de cabida útil contiene la PDU entramada para GFP con correspondencia de
tramas o, en el caso de GFP transparente, un grupo de caracteres de la señal cliente. Este campo de
longitud variable puede tener de 0 a 65 535-X octetos, siendo X el tamaño del encabezamiento de
cabida útil. Este campo puede incluir un campo FCS de cabida útil opcional. La PDU/señal cliente
siempre es transferida al campo de información de cabida útil de GFP como un tren de paquetes de
octetos alineados.
6.1.2.2.1 Campo secuencia de verificación de trama de cabida útil (pFCS)
La secuencia de verificación de trama de cabida útil GFP que se representa en la figura 6-8, es una
secuencia de verificación de trama opcional cuya longitud es de cuatro octetos. Contiene una
secuencia CRC-32 que protege el contenido del campo información de cabida útil GFP. El proceso
de generación de la FCS se define en 6.1.2.2.1.1. Un valor de 1 en el bit PFI del campo Tipo indica
que el campo FCS de cabida útil está presente.

Rec. UIT-T G.7041/Y.1303 (08/2005) 13

 Figura 6-8/G.7041/Y.1303 – Formato de la secuencia
de verificación de trama de cabida útil GFP

6.1.2.2.1.1 Generación de la secuencia de verificación de trama (FCS) de cabida útil

La FCS de cabida útil se genera utilizando el polinomio generador CRC-32 (ISO/CEI 13239)
G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x1 + 1, donde x32
corresponde al bit más significativo (MSB) y x0 corresponde al bit menos significativo (LSB).
Para generar el campo FCS de cabida útil se siguen estos pasos:
1) Los N octetos procedentes del campo información de cabida útil GFP, excluida la FCS, se
toman en el orden de octetos de la red, empezando por el bit más significativo, para formar
un esquema de 8N bits que representa los coeficientes de un polinomio M'(x) de grado
8N − 1.
2) M'(x) se multiplica por x32, se suma al polinomio "todos 1" U(x) = 1 + x1 + x2 + … + x31 y
se divide (módulo 2) por G(x), lo que da un residuo R(x) de grado 31 o inferior.
8N 1 2 31
NOTA – La adición de x [1 + x + x + … + x ] equivale a fijar previamente el registro de
desplazamiento a "todos 1" en las implementaciones de registro de desplazamiento típicas que
utilizan valores fijados previamente.
3) Se considera que los coeficientes de R(x) son una secuencia de 32 bit, donde x31 es el bit
más significativo.
4) El complemento de esta secuencia de 32 bits es la CRC-32.
El proceso de adaptación de sumidero sigue los pasos 1 a 3 de la misma forma que el proceso de
adaptación de fuente. Si no hay errores, el residuo será 11000111_00000100_11011101_01111011,
en el orden x31 a x0.
6.1.2.3 Aleatorización del área de cabida útil
Es necesario aleatorizar el área de cabida útil GFP para garantizar que la información de cabida útil
no reproduzca la palabra de aleatorización (o su inversa) procedente de un aleatorizador síncrono de
trama como los utilizados en la capa SDH RS o en un canal OTN OPUk. En la figura 6-9 se
representan los procesos aleatorizador y desaleatorizador.

Figura 6-9/G.7041/Y.1303 – Procesos aleatorizador

y desaleatorizador X43 + 1 para GFP

14 Rec. UIT-T G.7041/Y.1303 (08/2005)

Todos los octetos del área de cabida útil GFP se aleatorizan mediante un aleatorizador
autosincronizado 1 + x43. La aleatorización se efectúa en el orden de los bits de la red.
En el proceso de adaptación de fuente, la aleatorización se habilita empezando por el primer octeto
transmitido después del campo cHEC, y se inhabilita después del último octeto transmitido de la
trama GFP. Cuando el aleatorizador o desaleatorizador es inhabilitado, su estado se retiene. En
consecuencia, el estado del aleatorizador o desaleatorizador al principio de la cabida útil de una
trama GFP corresponde a los últimos 43 bits del área de cabida útil de la trama GFP transmitida en
ese canal inmediatamente antes de la trama GFP actual.
La activación del desaleatorizador del proceso de adaptación de sumidero también depende del
estado actual del algoritmo de comprobación cHEC:
a) En los estados HUNT y PRESYNC, el desaleatorizador está inhabilitado.
b) En el estado SYNC, el desaleatorizador está habilitado solamente para los octetos entre el
campo cHEC y el final de la trama GFP que va a ser tratada.
NOTA – El proceso de adaptación de sumidero GFP puede reenviar de una forma fiable tramas GFP a la
entidad de capa superior solamente cuando dicho proceso se encuentra en el estado SYNC.
6.1.3 Tramas cliente GFP
Actualmente están definidos dos tipos de tramas cliente GFP: de datos cliente y de gestión de
cliente. Las tramas de datos cliente GFP se utilizan para transportar datos a partir de la señal cliente.
Las tramas de gestión de cliente se utilizan para transportar información sobre la gestión de la señal
cliente o la conexión GFP.
6.1.3.1 Trama de datos cliente
Los datos cliente se transportan a través de GFP mediante tramas de datos cliente. Las tramas de
datos cliente son tramas cliente GFP formadas por un encabezamiento principal y un área de cabida
útil. El campo Tipo de las tramas de datos cliente utiliza los siguientes valores de subcampo Tipo:
• PTI = 000;
• PFI = específico de cabida útil;
• EXI = específico de cabida útil;
• UPI = específico de cabida útil.
El indicador FCS de cabida útil (PFI) se fijará como proceda, según que FCS esté o no habilitada.
El identificador de encabezamiento de extensión (EXI) se fijará según los requisitos de
multiplexación de trama y de topología para la conexión GFP. El identificador de cabida útil de
usuario se fijará según el tipo de señal cliente transportada. En el cuadro 6-3 se indican los valores
de UPI definidos para las tramas de datos cliente.

Rec. UIT-T G.7041/Y.1303 (08/2005) 15

 Cuadro 6-3/G.7041/Y.1303 – Identificadores de cabida útil
de usuario para las tramas cliente GFP
PTI = 000
Bits de Tipo
Área de cabida útil de trama GFP
<7:0>
0000 0000
Reservado y no disponible
1111 1111
0000 0001 Ethernet con correspondencia de trama
0000 0010 PPP con correspondencia de trama
0000 0011 Canal para fibra transparente
0000 0100 FICON transparente
0000 0101 ESCON transparente
0000 0110 Gb Ethernet transparente
0000 0111 Reservado para el futuro
0000 1000 Protocolo de acceso múltiple con correspondencia de trama a través de SDH (MAPOS)
0000 1001 DVB ASI transparente
0000 1010 Anillo de paquetes resistente IEEE 802.17 con correspondencia de trama
0000 1011 Canal para fibra con correspondencia de trama FC-BBW
0000 1100 Canal para fibra transparente asíncrono
0000 1101 MPLS con correspondencia de trama (unidifusión)
0000 1110 MPLS con correspondencia de trama (multidifusión)
0000 1111 IS-IS con correspondencia de trama
0001 0000 IPv4 con correspondencia de trama
0001 0001 IPv6 con correspondencia de trama
0001 0010 DVB ASI con correspondencia de trama
0001 0011 Reservado para normalización futura
a
1110 1111
1111 0000 Reservados para uso propietario (nota)
a
1111 1110
NOTA – La utilización de valores de código propietarios se describe en el anexo A/G.806.

6.1.3.2 Tramas de gestión de cliente GFP

Las tramas de gestión de cliente proporcionan un mecanismo genérico para el proceso de
adaptación de fuente específico de cliente GFP, para el envío facultativo de tramas de gestión de
cliente al proceso de adaptación de sumidero, específico de cliente GFP. Tal como se muestra en la
figura 6-10, las tramas de gestión de cliente son tramas cliente GFP formadas por un
encabezamiento principal y un área de cabida útil. El campo Tipo de las tramas de datos cliente
utiliza los siguientes valores de subcampo Tipo:
• PTI = 100;
• PFI = específico de cabida útil;
• EXI = específico de cabida útil;
• UPI = específico de cabida útil.

16 Rec. UIT-T G.7041/Y.1303 (08/2005)

 Figura 6-10/G.7041/Y.1303 – Trama de gestión de cliente GFP

Cuando se utiliza como una trama de gestión cliente GFP, el indicador de FCS de cabida útil (PFI)
se fijará como proceda, en función de que la FCS esté habilitada o no. (Téngase presente que la
utilización de FCS en tramas de gestión de cliente GFP reduce la cantidad de anchura de banda "de
reserva" que se puede utilizar para estas tramas.) El indicador de encabezamiento de extensión
(EXI) se fijará como proceda en función de que se emplee o no el encabezamiento de extensión.
(Téngase presente que la utilización del encabezamiento de extensión en una trama de gestión de
cliente GFP reduce significativamente la cantidad de anchura de banda "de reserva" que se puede
utilizar para estas tramas.)
El UPI define la utilización de la cabida útil de la trama de gestión cliente GFP. Esto permite
utilizar la trama de gestión cliente GFP para múltiples fines. En el cuadro 6-4 se indican diversos
usos de la cabida útil de la trama de gestión cliente GFP.

Rec. UIT-T G.7041/Y.1303 (08/2005) 17

 Cuadro 6-4/G.7041/Y.1303 – Identificador de la cabida útil de usuario
de la trama de gestión cliente GFP
PTI = 100
Valor del UPI Utilización
0000 0000
Reservados
1111 1111
0000 0001 Fallo de la señal cliente
(pérdida de la señal cliente)
0000 0010 Fallo de la señal cliente
(pérdida de sincronización de caracteres)
0000 0011 Reservados para usos futuros
a
1101 1111
1110 0000 Reservado para uso propietario
a (Nota)
1111 1110
NOTA – La utilización de valores de código propietarios se describe en el anexo A/G.806.

6.2 Tramas de control GFP

Las tramas de control GFP se utilizan en la gestión de la conexión GFP. La única trama de control
especificada hasta el momento es la trama Reposo GFP.
6.2.1 Trama Reposo GFP
La trama Reposo GFP es una trama especial de control GFP de cuatro octetos formada solamente
por un encabezamiento principal GFP con los campos PLI y cHEC (véase 6.1.1) puestos a 0, sin
área de cabida útil. La trama Reposo sirve de trama de relleno para el proceso de adaptación de
fuente GFP, con el fin de facilitar la adaptación del tren de octetos GFP a cualquier medio de
transporte dado cuando el canal del medio de transporte tenga una capacidad mayor que la
requerida para la señal cliente. El formato de la trama Reposo GFP se muestra en la figura 6-11;
entre paréntesis se indican los valores que se obtienen después de la aleatorización similar a la de
Barker.

Figura 6-11/G.7041/Y.1303 – Trama Reposo GFP

(trama aleatorizada por un proceso similar al de Barker)

6.2.2 Otras tramas de control

Las tramas de control con PLI = 1, 2 ó 3 quedan en estudio.

18 Rec. UIT-T G.7041/Y.1303 (08/2005)

6.3 Funciones a nivel de trama GFP
En esta cláusula se examinan los procesos a nivel de trama que son comunes a todas las cabidas
útiles entramadas mediante GFP. Los procesos que son específicos de determinados tipos de
cabidas útiles se examinan en las cláusulas 7 y 8. Las relaciones entre estos procesos se ilustran en
la figura 6-12.

Figura 6-12/G.7041/Y.1303 – Procedimientos comunes GFP

(independientes del protocolo)

6.3.1 Algoritmo de delimitación de la trama GFP

GFP utiliza una versión modificada del algoritmo de verificación HEC especificado
en 7.3.3.2/I.432.1, para proporcionar delimitación de trama GFP. El algoritmo de delimitación de
trama utilizado en GFP difiere del algoritmo de la Rec. UIT-T I.432.1 en dos aspectos esenciales:
a) El algoritmo utiliza el campo indicador de longitud de cabida útil del encabezamiento
principal GFP para encontrar el final de la trama GFP; y
b) En el cálculo del campo HEC se utiliza un polinomio de 16 bits y, en consecuencia, genera
un campo cHEC de dos octetos.
La delimitación de la trama GFP se efectúa a partir de la correlación entre los dos primeros octetos
de la trama GFP y el campo cHEC de dos octetos, insertado. La figura 6-13 representa el diagrama
de estados del método de delimitación de la trama GFP.
El diagrama de estados funciona como sigue:
1) En el estado HUNT, el proceso GFP efectúa la delimitación de la trama buscando, octeto
por octeto, un encabezamiento principal formateado correctamente en la última secuencia
de cuatro octetos recibida. Durante este estado, la corrección de errores simples del
encabezamiento principal está desactivada. Cuando se detecta una concordancia de cHEC
correcta en los campos PLI y cHEC que van a ser tratados (o candidatos), se identifica una
trama GFP candidata y el proceso de recepción pasa al estado PRESYNC.

Rec. UIT-T G.7041/Y.1303 (08/2005) 19

2) En el estado PRESYNC, el proceso GFP efectúa la delimitación de la trama verificando,
trama por trama, la concordancia correcta de cHEC en el supuesto encabezamiento
principal de la siguiente trama GFP candidata. El campo PLI en el encabezamiento
principal de la trama GFP precedente se utiliza para encontrar el comienzo de la siguiente
trama GFP candidata. La corrección de errores simples del encabezamiento principal
permanece inhabilitada por toda la duración de este estado. El proceso se repite hasta que se
confirman DELTA cHEC correctas consecutivas, en cuyo momento el proceso pasa al
estado SYNC. Si se detecta una cHEC incorrecta, el proceso vuelve al estado HUNT. El
número total de cHEC correctas consecutivas requeridas para transitar del estado HUNT al
estado SYNC es por tanto DELTA + 1.
3) En el estado SYNC, el proceso GFP efectúa la delimitación de trama verificando la
concordancia de una cHEC correcta en la siguiente trama GFP candidata. El campo PLI en
el encabezamiento principal de la trama GFP precedente se utiliza para encontrar el
comienzo de la siguiente trama GFP candidata. Durante este estado, la corrección de errores
bit simple en el encabezamiento principal está habilitada. La delimitación de tramas se
pierde cuando se detectan múltiples errores de bit en el encabezamiento principal mediante
la cHEC. En este caso, se declara un evento de pérdida de delimitación de trama GFP, el
proceso de entramado vuelve al estado HUNT, y se indica al proceso de adaptación de
cliente un fallo de señal de servidor (SSF, server signal failure) cliente.
4) Las tramas reposo GFP participan en el proceso de delimitación y después son descartadas.
Trama por trama
(corrección de errores desactivada)

Entramadores
PRESYNC virtuales PRESYNC
(hasta M)
(cHEC1D) (cHECMD)
Delta
cHEC
cHEC correctas
incorrecta consecutivas
PRESYNC PRESYNC
(cHEC11) (cHECM1)

cHEC cHEC
correcta correcta
HUNT SYNC
HEC incorrecta
(errores en varios bits)
Octeto por octeto Trama por trama
(corrección de errores desactivada) (corrección de errores desactivada)
G.7041/Y.1303_F6-13

Figura 6-13/G.7041/Y.1303 – Diagrama de estados de delimitación de tramas GFP

La robustez con respecto a una delimitación incorrecta en el proceso de resincronización depende

del valor de DELTA. Se propone un valor DELTA = 1.
Puede mejorarse la velocidad de adquisición de delimitación de tramas mediante la implementación
de múltiples "entramadores virtuales", en virtud de los cuales el proceso GFP permanece en el
estado HUNT y se genera un subestado PRESYNC separado para cada trama GFP candidata
detectada en el tren de octetos entrante, como se ilustra en la figura 6-13.

20 Rec. UIT-T G.7041/Y.1303 (08/2005)

6.3.2 Multiplexación de tramas
Las tramas GFP procedentes de varios puertos y de varios tipos de cliente se multiplexan trama por
trama. La elección de algoritmos de ordenación no es objeto de la presente Recomendación.
Cuando ya no existen otras tramas GFP disponibles para su transmisión, se insertarán tramas
Reposo GFP, con lo que se proporciona un tren continuo de tramas para la correspondencia con una
capa física alineada en octetos.
6.3.3 Indicación de fallo de la señal cliente
GFP proporciona un mecanismo genérico para que un proceso de adaptación de fuente específico de
cliente GFP propague una indicación de fallo de la señal cliente (CSF, client signal fail) hacia el
proceso de adaptación de sumidero específico de cliente GFP en el extremo distante al detectarse un
fallo en la señal cliente entrante.
Las reglas de detección de los eventos de fallo de la señal cliente son por definición específicas del
cliente (véanse las cláusulas 7 y 8). Tras la detección de uno de estos eventos, el proceso de
adaptación de fuente GFP debe generar una trama de gestión de cliente (PTI = 100). El subcampo
PFI se fija a 0 (sin FCS del campo de información de cabida útil), y el subcampo EXI se fija al tipo
de encabezamiento de extensión apropiado como corresponda. Los dos tipos de CSF, utilizan los
siguientes valores de campo UPI:
− Pérdida de la señal cliente (UPI = 0000 0001).
− Pérdida de la sincronización de los caracteres cliente (UPI = 0000 0010).
Al detectarse una condición CSF, el proceso de adaptación de fuente específico de cliente GFP debe
enviar indicaciones CSF hacia el proceso de adaptación de sumidero específico de cliente GFP en el
extremo distante una vez cada 100 ms ≤ T ≤ 1000 ms, comenzando en la siguiente trama GFP. Las
tramas interinas serán tramas Reposo GFP.
Al recibir la indicación CSF, el proceso de adaptación de sumidero de cliente GFP declara un fallo
de la señal cliente de sumidero. El tratamiento de los defectos se examina en 6.3.4.
El proceso de adaptación de sumidero específico de cliente GFP debe declarar desaparecida la
condición de defecto en cualquiera de estos dos casos:
1) cuando haya transcurrido un lapso de N × 1000 ms sin que se hayan recibido N indicaciones
CSF (se sugiere un valor de 3 para N); o
2) cuando se reciba una trama de datos cliente GFP válida.
El tratamiento de las tramas GFP incompletas al comienzo de un evento CSF debe ser consistente
con los procedimientos de tratamiento de errores especificados en 8.3 para GFP con
correspondencia transparente. La utilización de GFP con correspondencia de trama queda en
estudio.
6.3.4 Tratamiento de defectos en GFP
La figura 6-14 ilustra la relación causal entre diversos defectos detectados o indicados por el
proceso GFP. Los eventos de fallo de señal de camino (TSF, trail signal fail) se refieren a eventos
de fallo detectados en la red de transporte SDH u OTN, definidos en las Recs. UIT-T G.783 y
G.798. Los eventos de fallo de la señal de servidor GFP se refieren a eventos de pérdida de
delimitación de trama GFP definidos en la máquina de estados GFP (véase 6.3.1) o a la propagación
de eventos de TSF hacia los clientes GFP. Los eventos CSF se refieren a eventos de fallo detectados
en la señal cliente a la entrada (comunicados al extremo distante mediante una trama de gestión de
cliente CSF) o a la salida (defectos de correspondencia específicos del cliente tales como errores de
cabida útil; véanse las cláusulas 7 y 8).

Rec. UIT-T G.7041/Y.1303 (08/2005) 21

 Figura 6-14/G.7041/Y.1303 – Propagación de la señal con defecto en GFP

Al detectar un evento TSF o un evento GFP de pérdida de delimitación de trama, el proceso de

adaptación de sumidero GFP genera una indicación SSF de GFP y la envía a sus procesos de
adaptación de sumidero específicos cliente. Estos eventos de fallo son liberados tan pronto como el
proceso GFP recupera la sincronización del enlace.
Al detectar eventos CSF diferentes de una indicación CSF del extremo distante, los procesos de
adaptación de sumidero específicos cliente GFP deben ejecutar acciones específicas del cliente
(y también acciones específicas de servidor) para tratar esos eventos de fallo.

7 Aspectos específicos de cabida útil para GFP con correspondencia de trama

Esta cláusula describe aquellos aspectos del encapsulado genérico que son propios de la adaptación
de señales cliente, cuando la conversión de cabida útil cliente al GFP se efectúa trama por trama.

7.1 Cabida útil de MAC de Ethernet

El formato de las tramas MAC de Ethernet se define en la sección 3.1 de IEEE 802.3. Existe una
correspondencia biunívoca entre una PDU de capa superior y una PDU de GFP. Específicamente,
las demarcaciones de la PDU de GFP están alineadas con demarcaciones de las PDU de la capa
superior entramadas. Esta relación entre tramas MAC de Ethernet y tramas GFP se ilustra en la
figura 7-1.

Figura 7-1 G.7041/Y.1303 – Relaciones entre tramas de Ethernet y GFP

7.1.1 Encapsulado de MAC Ethernet

Los octetos MAC de Ethernet, desde la dirección de destino hasta la secuencia de verificación de
trama, inclusive, se colocan en el campo de información de cabida útil GFP. Se mantiene la división

22 Rec. UIT-T G.7041/Y.1303 (08/2005)

en octetos y la identificación de los bits dentro de los octetos. Específicamente, sobre una base
octeto por octeto, los bits 0 y 7 en la cláusula 3 de IEEE 802.3-2002 corresponden a los bits 8 y 1,
respectivamente, en esta Recomendación de GFP.
7.1.2 Supresión y restablecimiento del intervalo interpaquete (IPG, inter-packet gap)
Ethernet
Se aplican las siguientes reglas a la supresión y restauración de los IPG Ethernet cuando el cliente
no es un cliente de GFP con correspondencia de trama nativo:
1) Los IPG son suprimidos antes de que la trama MAC Ethernet sea tratada por el proceso de
adaptación de fuente GFP y restablecidos después de que la trama GFP sea tratada por el
proceso de adaptación de sumidero GFP.
2) Los IPG se suprimen cuando la trama MAC Ethernet se extrae del tren de bits cliente. La
trama MAC Ethernet extraída (decodificada) se reenvía entonces al proceso de adaptación
de fuente GFP para encapsulado ulterior en una trama GFP.
3) Los IPG son restablecidos después de que la trama MAC Ethernet ha sido extraída de la
trama GFP por el elemento de terminación GFP. La trama MAC Ethernet extraída (no
codificada) se reenvía entonces a la capa cliente para procesamiento ulterior. Los IPG se
restablecen asegurando que un número suficiente de octetos que contienen un patrón de
reposo hex 00 están presentes entre las tramas MAC Ethernet consecutivas recibidas, a fin
de satisfacer los requisitos mínimos IFG en el receptor. Estos requisitos se establecen en la
sección 4.4 de IEEE 802.3.

7.2 Cabida útil HDLC/PPP

La conversión directa de tramas HDLC/PPP en tramas GFP está prevista para aplicaciones que
quieran transportar tramas HDLC/PPP en modo nativo. La cabida útil HDLC/PPP se encapsula
naturalmente en una trama similar a la trama HDLC. El formato de una trama PPP se define en la
sección 2 de IETF RFC 1661. El formato de la trama similar a la trama HDLC se define en la
sección 3 de IETF RFC 1662. A diferencia de IETF RFC 1662, no se ejecuta ningún procedimiento
de relleno de octetos para identificar caracteres de bandera o de escape de control durante el proceso
de adaptación GFP. Existe una correspondencia biunívoca entre una PDU de PPP/HDLC de capa
superior y una PDU de GFP. Específicamente, las demarcaciones de la PDU de GFP están alineadas
con demarcaciones de las PDU de HDLC/PPP de capa superior entramadas. Esta relación entre una
trama de HDLC/PPP y una trama de GFP se ilustra en la figura 7-2.
Clientes similares, tales como MAPOS, se convierten de la misma manera que las tramas PPP.

Figura 7-2/G.7041/Y.1303 – Relación entre la trama HDLC/PPP y la GFP

Rec. UIT-T G.7041/Y.1303 (08/2005) 23

7.2.1 Encapsulado de la trama PPP
Todos los octetos procedentes de la trama de PPP/HDLC, incluyendo cualquier relleno opcional del
campo de información de PPP, se colocan en el campo de información de cabida útil de la trama de
GFP. Se mantiene la alineación de octetos y también la identificación de los bits dentro de los
octetos. Los bits 0 y 7 del octeto PPP/HDLC (véase ISO/CEI 13239) corresponden a los bits 8 y 1
del octeto de cabida útil GFP, respectivamente.
7.2.2 Interfuncionamiento de la delimitación de trama GFP/HDLC
A los efectos de delimitación de trama, GFP no se basa en caracteres bandera, ni en octetos de
escape de control asociados. Se aplican las siguientes reglas al procesamiento de las tramas de
HDLC con sincronización de octetos mediante una función de interfuncionamiento GFP/HDLC:
1) Se suprimen las banderas y los octetos de escape de control asociados (como se especifica
en la sección 4.2 de IETF RFC 1662), pues la trama PPP/HDLC se extrae del tren entrante
de octetos cliente. La trama PPP/HDLC extraída (decodificada) se reenvía a continuación al
proceso de adaptación de fuente GFP para encapsulado ulterior en una trama GFP.
2) La trama PPP/HDLC se extrae de la trama GFP. La trama PPP/HDLC extraída (no
codificada) se envía entonces a la capa cliente para procesamiento ulterior. Los caracteres
de banderas y de escape de control se restablecen seguidamente mediante la inserción de
caracteres bandera (por ejemplo hexadecimal 0x7e) y caracteres de control de escape (por
ejemplo hexadecimal 0x7d) como se especifica en la sección 4 de IETF RFC 1662.
7.2.3 Opciones de configuración de cabida útil PPP
Se pueden negociar modificaciones del formato de trama similar a la trama PPP/HDLC utilizando
los procedimientos de opciones de configuración del protocolo de configuración de enlace (LCP,
link configuration protocol) definidos en la sección 6 de IETF RFC 1661. Por ejemplo, en la
figura 7-3 se ilustra el formato de la trama GFP después de una negociación satisfactoria de la
opción de configuración compresión de campos de dirección y control (ACFC,
address-and-control-field compression). Tales procedimientos de configuración son específicos del
cliente y transparentes al proceso GFP.

Figura 7-3/G.7041/Y.1303 – Relaciones entre la trama PPP/HDLC

y la GFP (con la opción de configuración ACFC de PPP)

7.3 Cabida útil de canal para fibra a través de FC-BBW_SONET

El formato de una PDU de banda ancha sobre canal para fibra-2_SONET (FC-BBW_SONET) se
define en ANSI INCITS 342 (FC-BB), sección 6. A los efectos de la adaptación basada en GFP-F,
se supone una correspondencia biunívoca entre las PDU de canal para fibra y las PDU
FC-BBW_SONET (como en la especificación de FC-BB), y entre las PDU FC-BBW_SONET y

24 Rec. UIT-T G.7041/Y.1303 (08/2005)

las PDU GFP (como en esta Recomendación). En esta Recomendación sólo se especifica la relación
de correspondencia entre las PDU FC-BBW_SONET y las PDU GFP.
7.3.1 Encapsulado de PDU FC-BB-2_SONET
Todos los octetos de las PDU FC-BBW_SONET, desde el encabezamiento LLC/SNAP a la cabida
útil de mensaje BBW, inclusive, se sitúan en el campo de información de la cabida útil de la trama
GFP. La alineación de los octetos y la identificación de los bits en los octetos se mantienen en la
PDU GFP. La construcción del encabezamiento BBW y de la cabida útil de mensaje BBW (si
existe) de las PDU FC-BBW_SONET se especifica en ANSI INCITS 342. En la figura 7-4 se
muestra esta relación entre tramas FC-BBW_SONET y tramas GFP.

Figura 7-4/G7041/Y.1303 – Relaciones entre la PDU SONET de banda ancha

sobre canal para fibra-2 (FC-BBW SONET) y la trama GFP

7.4 Tratamiento de errores en GFP con correspondencia de trama

En ingreso, las PDU detectadas con error antes de la transmisión por el proceso de adaptación de
fuente de cliente deben ser descartadas. Las PDU detectadas con error durante la transmisión por el
proceso de adaptación de fuente de cliente deben rellenarse con una secuencia de bits de todos "1",
y transmitirse con una FCS de cabida útil que tiene los 32 bits complementados, si está presente.
Estas acciones aseguran que el proceso GFP de terminación, o el cliente de extremo, descartarán las
PDU con error.
7.4.1 Aspectos del fallo de la señal específica del cliente
Cuando el proceso de adaptación de fuente GFP con correspondencia de tramas detecta un fallo de
la señal cliente en el ingreso, es preferible, si es posible, generar un AIS de fallo de la señal cliente.
Cuando no se dispone de un AIS de señal cliente, es posible generar una CMF[csf] y el proceso de
adaptación de fuente GFP-F puede enviar una indicación "de fallo de la señal cliente", como se
indica en 6.3.3. Pueden codificarse como fallo de la señal cliente otras indicaciones de fallo de la
señal cliente dependientes de la implementación (por ejemplo, pérdida de reloj de una interfaz entre
circuitos integrados).
NOTA – En las Recs. UIT-T G.8021/Y.1341 y G.806 pueden encontrarse más detalles sobre el
procesamiento de esta señal y las acciones consiguientes.

Rec. UIT-T G.7041/Y.1303 (08/2005) 25

7.5 Cabida útil RPR IEEE 802.17
El formato de las tramas RPR se define en la sección 8 de IEEE 802.17. Existe una correspondencia
biunívoca entre una trama RPR y una PDU GFP. Para mayor claridad, la figura 7-5 ilustra la
relación entre las tramas RPR y las tramas GFP.

Figura 7-5/G.7041/Y.1303 – Relación entre las tramas RPR y GFP

7.5.1 Encapsulado RPR

Todos los octetos de la trama RPR (definida en la cláusula 8 de IEEE 802.17) se incluyen en el
campo información de cabida útil GFP. Por defecto no se utiliza la extensión de encabezamiento ni
el campo pFCS. Se mantiene la alineación de octeto y la identificación de bit dentro de los octetos.
Concretamente, en esta Recomendación GFP los bits LSB y MSB de cada octeto según la
cláusula 8 a la IEEE 802.17 y su anexo C corresponden, respectivamente a los bits 8 y 1. La
definición completa de este encapsulado figura en el anexo C a la IEEE 802.17.

7.6 Conversión directa de tramas MPLS en tramas GFP-F

La conversión directa de tramas MPLS en tramas GFP está prevista para aplicaciones que quieran
transportar PDU MPLS complementarias directamente en contenedores SDH. La PDU MPLS, de
unidifusión o de multidifusión, contiene una o más entradas de pila de etiquetas específicas del
MPLS (como se indica en RFC 3032) y un campo de información de cabida útil MPLS. Todos los
octetos de la PDU MPLS se sitúan en el campo información de cabida útil de la trama GFP-F. Se
mantienen en la PDU GFP-F tanto la alineación de los octetos como la identificación de bits dentro
de los octetos. Esta conversión directa de las tramas MPLS en GFP debería ser la conversión por
defecto cuando las señales de cliente MPLS se transportan directamente por una red de transporte.
Es necesario que haya una FCS de cabida útil GFP que se computará como se especifica en
6.1.2.2.1.1 y se insertará en el campo pFCS. El campo PFI se pone a 1.
La relación entre las tramas PDU MPLS y GFP-F es la que se muestra en la figura 7-6.

26 Rec. UIT-T G.7041/Y.1303 (08/2005)

 Figura 7-6/G.7041/Y.1303 – Relaciones entre las tramas PDU MPLS y GFP

7.7 Conversión directa de las PDU IP e IS-IS en tramas GFP-F

La conversión directa de las PDU Ipv4, Ipv6 y OSI en GFP se utiliza en aplicaciones que desean
transportar PDU IP/OSI directamente en contenedores SDH. La PDU IPv4 (IETF
RFC 791/STD0005), la PDU IPv6 (IETF RFC 2460) y la PDU IS-IS (OSI/CEI 10589) contienen
una o varias entradas de encabezamiento específicas del cliente y un campo de información de
cabida útil del cliente. Todos los octetos de la PDU del cliente se ubican en el campo Información
de cabida útil de la trama GFP-F. La alineación de octetos y la identificación de los bits de los
octetos se mantienen dentro de la PDU GFP-F.
Es necesaria la FCS de cabida útil GFP, que se calcula según lo indicado en 6.1.2.2.1.1 y se inserta
en el campo pFCS. El campo PFI se pone a 1. La relación entre las PDU IPv4, IPv6 e IS-IS y la
trama GFP-F se ilustra en la figura 7-7.

Figura 7-7/G.7041/Y.1303 – Relación entre las PDU IPv4/IPv6/IS-IS y la trama GFP

7.8 Cabida útil de la DVB ASI

En EN 50083-9 se definen los formatos de los paquetes del tren de transporte (TS, transport
stream) como de 188 bytes o de 204 bytes, denominándose estos últimos formato paquetes TS con
codificación RS (Reed-Solomon). Existe una correspondencia biunívoca entre los paquetes TS (o
los paquetes TS con codificación RS) y las PDU GFP. Específicamente, las fronteras de las
PDU GFP se alinean con las fronteras de los paquetes TS (o de los paquetes TS con codificación

Rec. UIT-T G.7041/Y.1303 (08/2005) 27

RS). Esta relación entre los paquetes TS (o los paquetes TS con codificación RS) y las tramas GFP
se muestra en la figura 7-8.

Figura 7-8/G.7041/Y.1303 – Relación entre los paquetes TS y las tramas GFP

7.8.1 Encapsulación de la DVB ASI

Los 188 ó 204 octetos de los paquetes TS se colocan en el campo de información de cabida útil
GFP. Se mantiene la alineación de los octetos así como la identificación de los bits dentro de los
octetos conforme a ISO/CEI 13818-1. Específicamente, octeto por octeto, los bits de datos d7 y d0
(correspondientes a los caracteres de información H y A en 8B) en EN 50083-9 para DVB ASI
corresponden respectivamente a los bits 1 y 8 del byte de cabida útil.
7.8.2 Operaciones DVB ASI
7.8.2.1 Operaciones en la interfaz de ingreso DVB ASI
En la interfaz de ingreso, los bytes de datos y su reloj se recuperan de la señal DVB ASI recibida,
cuyo procesamiento incluye un receptor óptico (para los enlaces de fibra óptica) o
acoplamiento/adaptación de impedancia (para cable coaxial), un amplificador/memoria intermedia,
la recuperación de reloj/datos y la conversión serie/paralelo, la supresión de símbolos de coma FC,
la decodificación 8B/10B, como se especifica en el anexo B de ETSI EN 50083-9.
7.8.2.1.1 Pérdida de luz (LOL) DVB ASI
Por referencia a las normas de los canales de fibra, la pérdida de señal DVB ASI es una opción
dependiente de la implementación. Los requisitos aplicables a la pérdida de luz y detección de
señales, si se soportan, figuran en las secciones 5.6, 6.2.3.2 y H.10 de ANSI INCITS 230, Fibre
Channel Physical and Signalling Interface (FC-PH), Rev. 4.3.
7.8.2.1.2 Pérdida de sincronización 8B/10B DVB ASI
De acuerdo con el apéndice B de ETSI EN 50083-9 la sincronización de la palabra de código DVB
ASI deberá efectuarse mediante recepción de dos caracteres /K28.5/ con la misma alineación en
5 caracteres consecutivos recibidos. Los criterios de pérdida de sincronización de la palabra de
código por caracteres ESCON/SBCON serán los especificados en ANSI INCITS 296, sección 7.1.
NOTA − En ETSI EN 50083-9 no se especifican criterios para la declaración de la pérdida de sincronización
de la palabra de código. Tal vez no se apliquen criterios de canal de fibra, ya que la sincronización de la
palabra de código DVB ASI y su transmisión se hace por caracteres, y no es una transmisión de cuatro
caracteres por palabras.
7.8.2.2 Operaciones de ingreso de paquetes TS
Esta función realiza la adquisición de sincronización de los paquetes TS MPEG-2, o de los paquetes
TS MPEG-2 con codificación RS, de acuerdo con el método propuesto en la subcláusula 5.2 de
ETSI TR 101 290 (cinco bytes de sincronización correctos consecutivos para la adquisición de

28 Rec. UIT-T G.7041/Y.1303 (08/2005)

sincronización; dos o más bytes de sincronización corrompidos consecutivos indican la pérdida de
sincronización).
El tamaño del paquete (188 bytes o 204 bytes) puede obtenerse de las señales recibidas, de acuerdo
con la periodicidad de los bytes de sincronización.
En caso de fallo del cliente de ingreso (por pérdida de señal, pérdida de sincronización de caracteres
o pérdida de sincronización de paquetes) no será posible delimitar ningún paquete. De hecho, la
imposibilidad de delimitar los paquetes provoca la generación de tramas de reposo GFP
únicamente.
La función de encapsulación GFP-F utiliza PFI="0" (no hay FCS de cabida útil) y EXI="0000"
(encabezamiento de extensión nulo).
7.8.2.3 Operaciones de egreso de paquetes TS
En la interfaz de egreso, la función de desencapsulación GFP-F elimina el encabezamiento
principal, desaleatoriza el área de cabida útil, transmite el paquete TS (o el paquete TS con
codificación RS) al siguiente bloque, incluso en caso de tHEC incorregible, suponiendo las
condiciones del tipo por defecto. El tipo de paquete (paquete TS MPEG-2 o paquete TS MPEG-2
con codificación RS) se determina a partir de la longitud de la trama GFP recibida.
Para recuperar la información de temporización del paquete TS (o del paquete TS con
codificación RS) y eliminar la fluctuación de fase del paquete recibido (debida a las tramas GFP en
reposo, a los movimientos del puntero, etc.), es necesario disponer de un método de sincronización
de extremo a extremo. El método que se utilizará es el método del reloj adaptable que se describe en
la Rec. UIT-T I.363.1.
NOTA – Este método es adecuado por no ser necesario en el caso de transporte de programas de vídeo
comprimidos para satisfacer las especificaciones de fluctuación lenta de fase de la Rec. UIT-T G.823.
Además, el método del reloj adaptable no depende de la disponibilidad de un reloj de referencia externo. La
sincronización de extremo a extremo de los paquetes TS (o de los paquetes TS con codificación RS) puede
recuperarse a partir del tiempo de llegada de las tramas GFP recibidas.
La fluctuación de fase de los paquetes de transporte deberá satisfacer los requisitos de fluctuación
de fase de ISO/CEI 13818-9.
7.8.2.4 Operaciones de la interfaz de egreso DVB ASI
Este procesamiento incluye la codificación 8B/10B, la inserción de símbolos de coma FC, la
conversión paralelo a en serie, un amplificador, la adaptación de la memoria intermedia del
amplificador y el emisor óptico (en los enlaces de fibra óptica) o de las impedancias de
acoplamiento (cuando se trata de cable coaxial), como se especifica en el anexo B de
ETSI EN 50083-9.
Las disparidades de funcionamiento habrán de respetar la norma sobre canales de fibra, especificada
en ANSI INCITS 230, Fibre Channel-Physical and Signalling Interface (FC-PH), Rev. 4.3,
sección 11.
Cuando la memoria intermedia receptora está infrautilizada, el transmisor DVB ASI de egreso
deberá emitir continuamente la palabra de código de disparidad neutra 10B, dependiendo de la
disparidad de funcionamiento inicial (RD–) o (RD+), de acuerdo con lo descrito en 8.1.1.1,
forzando la detección de pérdida de sincronización así como cualquier medida relacionada en el
receptor DVB ASI en sentido descendente.

Rec. UIT-T G.7041/Y.1303 (08/2005) 29

8 Aspectos específicos de la cabida útil para la conversión transparente de
clientes 8B/10B a GFP
La conversión transparente de las cabidas útiles 8B/10B a GFP tiene por objeto facilitar el
transporte de señales cliente codificadas en bloque 8B/10B en los casos que requieren muy baja
latencia de transmisión. Son ejemplos de tales señales cliente el canal de fibra, ESCON, FICON y
Gigabit Ethernet. En lugar de almacenar (temporalmente) una trama completa de datos cliente en su
propia trama GFP, los caracteres individuales de la señal cliente se sacan de los códigos de bloque
cliente suprimiendo la conversión y convirtiéndose a continuación en tramas GFP periódicas de
longitud fija. La conversión se realiza independientemente de que el carácter cliente sea un carácter
de datos o de control, lo cual preserva los códigos de control 8B/10B clientes. No se excluye la
multiplexación de tramas con GFP transparente.

8.1 Aspectos comunes de GFP-T

La trama GFP transparente utiliza la misma estructura de trama que la GFP con correspondencia de
trama, incluyendo el encabezamiento de cabida útil requerido. La FCS de cabida útil es opcional. El
formato de trama GFP transparente se ilustra en la figura 8-1.

Figura 8-1/G.7041/Y.1303 – Formato de trama GFP transparente

8.1.1 Adaptación de señales cliente 8B/10B a través de códigos de bloque 64B/65B

Como se muestra en el modelo funcional de la figura 2, el primer paso en el proceso de adaptación
de cliente es la decodificación de la capa física de la señal cliente. Para códigos de línea 8B/10B, el
carácter de 10 bits recibido se decodifica a su valor original de 8 bits, si es una palabra código de
datos 8B/10B, o a un carácter de control si es una palabra código de control 8B/10B. Las palabras
código de control 8B/10B se hacen corresponder con uno de los 16 posibles indicadores de código
de control de 4 bits para los caracteres de control de 8 bits disponibles en GFP transparente. (Véase
el cuadro 8-1.)

30 Rec. UIT-T G.7041/Y.1303 (08/2005)

 Cuadro 8-1/G.7041/Y.1303 – Correspondencia entre caracteres de control 8B/10B
y los indicadores de código de control 64B/65B
Palabra de código Palabra de
Valor del Correspondencia de
Nombre 10B (RD–) código 10B (RD+)
octeto 4 bits de 64B/65B
abcdei fghj abcdei fghj
/K28.0/ 1C 001111 0100 110000 1011 0000
/K28.1/ 3C 001111 1001 110000 0110 0001
/K28.2/ 5C 001111 0101 110000 1010 0010
/K28.3/ 7C 001111 0011 110000 1100 0011
/K28.4/ 9C 001111 0010 110000 1101 0100
/K28.5/ BC 001111 1010 110000 0101 0101
/K28.6/ DC 001111 0110 110000 1001 0110
/K28.7/ FC 001111 1000 110000 0111 0111
/K23.7/ F7 111010 1000 000101 0111 1000
/K27.7/ FB 110110 1000 001001 0111 1001
/K29.7/ FD 101110 1000 010001 0111 1010
/K30.7/ FE 011110 1000 100001 0111 1011
10B_ERR 01 RD– No reconocido RD+ No reconocido 1100
65B_PAD 02 N/A N/A 1101
Reserva 03 N/A N/A 1110
Reserva 04 N/A N/A 1111
NOTA 1 − Si bien los 256 caracteres de datos tienen que estar soportados, sólo 12 palabras código de
control 8B/10B especiales son reconocidas y utilizadas para caracteres de control 64B/65B en Gigabit
Ethernet, Canal de fibra, FICON y ESCON. Por consiguiente, es posible la compresión de palabras código
de control 8B/10B especiales, en valores de 4 bits, sin restringir las señales cliente, ni proporcionar un
tratamiento específico de protocolo de las palabras código de control 8B/10B.
NOTA 2 − El proceso de recodificación ignora completamente el significado de las palabras de control o
de los conjuntos ordenados. Dicho proceso, simplemente, recodifica genéricamente datos y palabras de
control en bloques 65B. No se requiere el conocimiento de inicio de trama, fin de trama, errores, reposos,
código de control, conjuntos ordenados, etc.

Los caracteres 8B/10B decodificados se hacen corresponder entonces con un código de bloque de
64 bits/65 bits (64B/65B). En la figura 8-2 se ilustra la estructura del código de bloque 64B/65B. El
bit inicial del bloque de 65 bits, bit de bandera, indica si ese bloque contiene solamente caracteres
de datos de 8 bits 64B/65B o si también están presentes caracteres de control de cliente en ese
bloque. (Bit de bandera = 0 indica que en el bloque sólo hay octetos de datos y bit de bandera = 1
indica que hay al menos un octeto de control.) Los caracteres de control de cliente, que se hacen
corresponder a caracteres de control 64B/65B de 8 bits, se colocan al principio del bloque de 64 bits
de la cabida útil, si están presentes en ese bloque. El primer bit del carácter de control 64B/65B
contiene un bit de bandera último carácter de control (LCC, last control character), que indica si
este carácter de control es el último en este bloque (LCC = 0), o si hay otro carácter de control en el
siguiente octeto (LCC = 1). Los siguientes tres bits contienen el localizador de código de control,
que indica la posición original del carácter de código de control 8B/10B dentro de la secuencia de
ocho caracteres cliente contenidos en el bloque. Los últimos 4 bits, el indicador de código de
control, representan mediante 4 bits el carácter de código de control 8B/10B. En el cuadro 8-1 se
define la correspondencia explícita de caracteres de código de control 8B/10B a códigos de control
de 4 bits. Los códigos de control se trasladan a los octetos de la cabida útil del código 64B/65B en

Rec. UIT-T G.7041/Y.1303 (08/2005) 31

el orden en el que se recibieron. Obsérvese que, como resultado de esto, las direcciones de código
de control aaa-hhh en la figura 8-2 están en orden ascendente.

Caracteres de
Bit de
cliente Campo de 64 bits (8 octetos)
bandera
de entrada
Todos datos 0 D1 D2 D3 D4 D5 D6 D7 D8
7 datos, 1 0 aaa D1 D2 D3 D4 D5 D6 D7
1 control C1
6 datos, 1 1 aaa 0 bbb D1 D2 D3 D4 D5 D6
2 control C1 C2
5 datos, 1 1 aaa 1 bbb 0 ccc D1 D2 D3 D4 D5
3 control C1 C2 C3
4 datos, 1 1 aaa 1 bbb 1 ccc 0 ddd D1 D2 D3 D4
4 control C1 C2 C3 C4
3 datos, 1 1 aaa 1 bbb 1 ccc 1 ddd 0 eee D1 D2 D3
5 control C1 C2 C3 C4 C5
2 datos, 1 1 aaa 1 bbb 1 ccc 1 ddd 1 eee 0 fff D1 D2
6 control C1 C2 C3 C4 C5 C6
1 datos, 1 1 aaa 1 bbb 1 ccc 1 ddd 1 eee 1 fff 0 ggg D1
7 control C1 C2 C3 C4 C5 C6 C7
8 control 1 1 aaa 1 bbb 1 ccc 1 ddd 1 eee 1 fff 1 ggg 0 hhh
C1 C2 C3 C4 C5 C6 C7 C8
− Bit inicial en un octeto de control (LCC) = 1 si hay más octetos de control y = 0 si este octeto de cabida útil contiene el
último octeto de control en ese bloque.
− aaa = representación en 3 bits de la posición original del primer código de control (primer localizador de código de control).
− bbb = representación en 3 bits de la posición original del segundo código de control (segundo localizador de código de
control).
...
− hhh = representación en 3 bits de la posición original del octavo código de control (octavo localizador de código de control).
− Ci = representación en 4 bits del iésimo código de control (indicador de código de control).
− Di = representación en 8 bits del iésimo valor de datos en el orden de transmisión

Figura 8-2/G.7041/Y.1303 − Componentes del código 64B/65B GFP transparente

(para la estructura de superbloque real, véase la figura 8-3)

Por ejemplo, si existe un solo carácter de control 64B/65B en un bloque y dicho carácter se
encontraba inicialmente entre las palabras código de datos 8B/10B D2 y D3, el primer octeto del
bloque 64B/65B contendrá 0.010.C1. El valor 0 de LCC indica que este carácter de
control 64B/65B es el último en ese bloque y el valor de aaa = 010 indica la posición de C1 entre
D2 y D3. En el dispositivo de anulación de correspondencia, los caracteres de datos 64B/65B se
reconvierten en octetos de datos (de 8 bits) y a continuación se vuelven a codificar como palabras
de código de datos 8B/10B. En el caso de caracteres de control 64B/65B, los indicadores de código
de control de cuatro bits se reconvierten en las palabras de código de control 8B/10B apropiadas
con sus posiciones dentro del tren de caracteres inicial restablecidas atendiendo al localizador de
código de control de tres bits.
8.1.1.1 Código 10B_ERR
Ciertos defectos de la señal cliente pueden producir palabras código 8B/10B cuando se produce el
ingreso al proceso de adaptación de fuente GFP que no pueden ser reconocidas por el proceso de
adaptación 64B/65B (por ejemplo un fallo de la señal cliente, una palabra código 8B/10B ilegal o
una palabra código legal con un error de disparidad de funcionamiento; véase 8.2). Se proporciona
un carácter de control 64B/65B especial, el código 10B_ERR, para transportar tales defectos de la
señal cliente "palabra código 8B/10B no reconocida".

32 Rec. UIT-T G.7041/Y.1303 (08/2005)

Cuando se reconstruye la señal cliente en el egreso de la red de transporte, se recomienda que los
códigos 10B_ERR recibidos sean normalmente recodificados por el dispositivo de anulación de
correspondencia en un carácter de transmisión no válido, ya sea 001111 0001 (RD−) u 110000 1110
(RD+) (palabras código 8B/10B ilegales fijas, con disparidad neutra, con una transición dentro de
los tres primeros bits y en los tres últimos bits de la palabra código), en función de la disparidad de
funcionamiento (véanse en 8.2.3 otras consideraciones sobre disparidad de funcionamiento
específicas del cliente). Aunque el valor real de la palabra código 8B/10B no reconocida no se
retiene, se conserva la ocurrencia y ubicación del defecto de señal cliente.
Además del carácter de transmisión no válido recomendado (cuya construcción minimiza la posible
creación de comas superpuestas cuando están combinados con caracteres adyacentes), también
puede anularse la correspondencia de eventos 10B_ERR, utilizando en su lugar caracteres de
transmisión no válidos alternativos, siempre que dichos caracteres de transmisión no válidos
alternativos cumplan también todas las normas de codificación 8B/10B, sean de una disparidad
neutra y contengan un número mínimo de transiciones a uno en los primeros y los últimos cuatro
bits de la palabra código.
8.1.1.2 Inserción del código 65B_PAD y tramas de gestión de cliente GFP
Puesto que la aplicación GFP transparente requiere que la capacidad de trayecto (o de canal)
disponible sea al menos la de la velocidad de datos (antes de la codificación) base de la señal
cliente, la memoria intermedia de recepción de entrada (ingreso) del dispositivo de correspondencia
se aproximará regularmente al límite inferior. Para fines de adaptación de velocidad, si hay una
trama GFP transparente en curso de transmisión y si no hay caracteres cliente listos para su
transmisión por el dispositivo de correspondencia GFP transparente, este dispositivo insertará un
carácter de relleno 65B_PAD. El carácter de relleno se hace corresponder con la trama GFP de la
misma manera que un carácter de control y es reconocido y suprimido por el dispositivo de
anulación de correspondencia GFP. En 8.4.1 se hacen consideraciones específicas del cliente sobre
el tratamiento del código 65B_PAD.
Las tramas de datos cliente se transmiten con prioridad sobre las tramas de gestión de cliente. Si una
trama de gestión de cliente GFP está disponible para ser transmitida, y la memoria intermedia de
ingreso está casi vacía (por ejemplo, si se ha enviado un carácter 65B_PAD durante la trama de
datos cliente en curso), se puede enviar la trama de gestión de cliente después de la trama de datos
cliente en curso. Con el fin de mantener una baja latencia, se recomienda que para un canal de
tamaño correcto se envíe únicamente una sola trama de gestión de cliente entre tramas de datos
cliente. También se recomienda que las tramas de gestión de cliente utilizadas con GFP transparente
se limiten a un campo de información de cabida útil de ocho octetos o menos. Obsérvese que
también se puede mantener una baja latencia aumentando el tamaño del canal para permitir el
intercambio de tramas de gestión de cliente adicionales.
8.1.2 Adaptación de bloques de código 64B/65B en GFP
Para preservar la alineación en octetos de la señal GFP transparente con la trama SDH/ODUk de
transporte, el primer paso en el proceso de adaptación es agrupar ocho códigos 64B/65B en un
superbloque como se muestra en la figura 8-3. Los bits iniciales (bandera) de cada uno de los ocho
códigos 64B/65B se agrupan en un primer octeto posterior. Los 16 bits de los últimos dos octetos
posteriores se utilizan para una verificación de errores CRC-16 sobre los bits de este superbloque.

Rec. UIT-T G.7041/Y.1303 (08/2005) 33

 Octeto 1, 1
Octeto 1, 2
Octeto 1, 3
.
.
.
Octeto 8, 7
Octeto 8, 8
L1 L2 L3 L4 L5 L6 L7 L8
CRC-1 CRC-2 CRC-3 CRC-4 CRC-5 CRC-6 CRC-7 CRC-8
CRC-9 CRC-10 CRC-11 CRC-12 CRC-13 CRC-14 CRC-15 CRC-16
donde: Octeto j, k es el késimo octeto del jésimo código 64B/65B en el superbloque.
Lj es el jésimo bit inicial (bandera) del código 64B/65B en el superbloque.
CRC-i es el iésimo bit de control de error, donde CRC-1 es el MSB de la CRC.

Figura 8-3/G.7041/Y.1303 − Estructura de superbloque para la conversión

de los componentes de código 64B/65B en la trama GFP
NOTA – Para minimizar la latencia, el dispositivo de conversión GFP transparente puede comenzar a
transmitir datos tan pronto se forme el primer código 64B/65B en el grupo, sin esperar a que se forme el
superbloque completo.
Suponiendo que no exista FCS de cabida útil y que haya un encabezamiento de extensión nulo, la
trama GFP resultante tendrá una longitud de [(N × ((65 × 8) +16) + (8 × 8)] bits, siendo N el
número de superbloques de la trama GFP. El valor de N depende de la velocidad de base, no
codificada, de la señal cliente y de la capacidad del canal de transporte. En el apéndice IV se
indican las capacidades propuestas para el canal concatenado virtualmente SDH y los valores
mínimos de N asociados. Las capacidades de canal propuestas para otros trayectos de transporte
quedan en estudio. El valor mínimo de N depende de la velocidad de datos de la señal cliente, del
número de los octetos de tara de la trama GFP (por ejemplo, 8 sin FCS opcional de cabida útil y con
un encabezamiento de extensión nulo), y el tamaño de la envolvente de cabida útil, como se muestra
en el apéndice IV. Específicamente, Nmín debe elegirse de tal manera que para la velocidad de reloj
cliente con la tolerancia más rápida y la velocidad de reloj de SDH/OTN con la tolerancia más
lenta, el tiempo requerido para la transmisión de la trama GFP que contiene los N × 8 × 8 caracteres
clientes sea menor que el tiempo en el que el cliente puede entregar estos N × 8 × 8 caracteres al
dispositivo de conversión GFP.
Obsérvese que N puede ser configurable si así se desea de conformidad con los requisitos de
anchura de banda de reserva para el transporte de tramas de gestión del cliente. Véase el
apéndice IV.
8.1.2.1 Control de errores con GFP transparente
Los 16 bits de control de errores de un superbloque (véase la figura 8-3) contienen un código de
verificación de errores CRC-16 sobre los 536 bits de dicho superbloque. Si el dispositivo de
anulación de correspondencia detecta un error, deberá entregar a la salida ya sea caracteres de
error 10B o caracteres 10B no reconocidos en lugar de todos los caracteres clientes contenidos en
dicho superbloque. Los caracteres de error 10B y los caracteres no reconocidos se describen, a los
efectos de errores de disparidad, en los aspectos específicos del cliente (véase 8.2). Esta sustitución
garantiza que el receptor del cliente podrá detectar la presencia del error.
El polinomio generador de CRC-16 es G(x) = x16 + x15 + x12 + x10 + x4 + x3 + x2 + x + 1 con un
valor de inicialización de cero, donde x16 corresponde al MSB y x0 al LSB. La CRC del
superbloque la genera el proceso de adaptación de fuente mediante los siguientes pasos:

34 Rec. UIT-T G.7041/Y.1303 (08/2005)

1) Los primeros 65 octetos del superbloque se toman en el orden de los octetos en la red
(véase la figura 8-3), en primer lugar el bit más significativo, para formar un esquema
de 520 bits que representa los coeficientes de un polinomio M(x) de grado 519.
2) M(x) se multiplica por x16 y se divide (módulo 2) por G(x), lo que da un residuo R(x) de
grado 15 o menos.
3) Se considera que los coeficientes de R(x) son una secuencia de 16 bits, donde x15 es el bit
más significativo.
4) Esta secuencia de 16-bits es la CRC-16.
NOTA – La corrección de errores simples también es posible con esta CRC-16. Sin embargo, como el
proceso de adaptación de sumidero efectúa la verificación CRC-16 después de la desaleatorización de la
cabida útil, el circuito de corrección de errores deberá tener en cuenta los errores de bit simples así como los
errores dobles que aparezcan a la salida del desaleatorizador con una separación de 43 bits.
El proceso de adaptación de sumidero ejecuta los pasos 1 a 3 de la misma manera que el proceso de
adaptación de fuente. En la ausencia de errores de bit, el residuo será 0000 0000 0000 0000.

8.2 Disparidad de funcionamiento en los códigos 64B/65B

Las palabras código 8B/10B están diseñadas para facilitar la transmisión exenta de errores
manteniendo un equilibrio de corriente continua, proporcionando transiciones significativas para la
recuperación del reloj, y limitando series prolongadas de 1 ó 0 consecutivos. El equilibrio de
corriente continua se mide para cada palabra código controlando la "disparidad de funcionamiento".
La disparidad de funcionamiento puede ser positiva (lo que indica que se han enviado más 1 que 0)
o negativa (más 0 que 1).
A fin de mantener un equilibrio de corriente continua en las palabras de código 8B/10B, cada
carácter de datos de 8 bit y cada uno de los 12 "caracteres de control especiales" reconocidos tienen
dos codificaciones de 10 bits. En función de la disparidad de funcionamiento en un momento dado,
el codificador 8B/10B seleccionará cuál de las dos codificaciones se utilizará para transmitir el
siguiente carácter de datos o de control con objeto de invertir la disparidad de funcionamiento o de
mantener la actual disparidad de funcionamiento. Específicamente, la nueva palabra de código
invierte la disparidad de funcionamiento, de negativa a positiva si se han transmitido más 0 que 1,
de positiva a negativa si se han transmitido más 1 que 0, o mantiene la disparidad de
funcionamiento si ha transmitido un número igual de 1 y 0.
Los errores en los bits en la transmisión pueden hacer que una palabra de código 8B/10B recibida
tenga una disparidad errónea para el actual estado de disparidad de funcionamiento de comienzo.
En estos casos, se detecta un error de disparidad de funcionamiento. Independientemente de la
validez del carácter recibido, este carácter se debe utilizar para calcular un nuevo valor de
disparidad de funcionamiento. El nuevo valor se utilizará como la actual disparidad de
funcionamiento del receptor para el siguiente carácter de transmisión recibido.
NOTA – Los errores de bits de transmisión pueden provocar asimismo que la palabra código errónea se
reciba con disparidad correcta y que una palabra de código 8B/10B corrompida pero legal, que genere una
palabra de código sin errores se detecte con un error de disparidad de funcionamiento. En algunos casos se
han creado reglas de disparidad de funcionamiento específicas del protocolo para asegurar que cada paquete
de datos comienza o termina con una disparidad definida, de manera que los errores no se propaguen a través
de los paquetes de datos.
8.2.1 Tratamiento de la disparidad de funcionamiento en ingreso
En el ingreso (entrada), puede suponerse que la disparidad de funcionamiento inicial es positiva o
negativa tras el encendido, la reinicialización o la transición de una pérdida de señal o pérdida de la
fase de sincronización de la palabra código.
Se busca una concordancia con el carácter 10B recibido en la columna RD+ o RD− apropiada de la
tabla de consulta de palabras clave válidas 8B/10B, lo cual es función de la disparidad de

Rec. UIT-T G.7041/Y.1303 (08/2005) 35

funcionamiento actual que comienza. Si no se encuentra una concordancia, se detecta una palabra
código ilegal o una palabra código legal con un error de disparidad de funcionamiento. Ambas se
tratan como violaciones de código 8B/10B, y se sustituyen por el código 10B_ERR en el proceso de
correspondencia 64B/65B.
8.2.2 Tratamiento de la disparidad de funcionamiento en egreso
En el egreso (salida), se supone que la disparidad de funcionamiento inicial tras el encendido,
reinicialización, o transición de una pérdida de señal o pérdida de la fase de sincronización de la
palabra código, es negativa.
Las implementaciones de transporte transparente generarán una disparidad de funcionamiento
correcta utilizando reglas aplicables específicas del protocolo. En 8.2.3 se proporcionan referencias
a la norma o normas que definen cada una de las reglas de disparidad del protocolo actualmente
aplicables.
Los códigos 10B_ERR se recodifican en señales clientes ya sea como una palabra código no
reconocida con una disparidad de funcionamiento válida, o como un error específico del protocolo,
lo que depende del protocolo, como se describe en 8.2.3.
8.2.3 Aspectos de la disparidad de funcionamiento específicos del cliente
Esta cláusula describe las reglas de disparidad de funcionamiento específicas de cliente para cada
uno de los protocolos cliente 8B/10B soportados que se identifican.
8.2.3.1 Cabida útil del canal de fibra
En ANSI INCITS 230, Fibre Channel-Physical and Signalling Interface (FC-PH), Rev 4.3,
sección 11, se encuentran las reglas de disparidad de funcionamiento para los canales de fibra.
Además de las reglas de disparidad de funcionamiento "genéricas" especificadas en la sección 11.2,
las reglas específicas para los canales de fibra de la sección 11.4 proporcionan dos versiones de
cada conjunto ordenado EOF, y establecen su utilización para asegurar que se obtendrá como
resultado una disparidad de funcionamiento negativa después del procesamiento del carácter final
del conjunto ordenado EOF. Los conjuntos ordenados definidos para las señales primitivas y para
las secuencias primitivas preservan esta disparidad negativa, asegurando que los conjuntos
ordenados asociados con los delimitadores SOF y las señales primitivas serán también siempre
transmitidos con una disparidad de funcionamiento de comienzo negativa. Esta restricción permite
que se supriman y se añadan las palabras en reposo de Canal para fibra desde un tren de bits
codificado en base a una palabra cada vez sin alterar la disparidad de funcionamiento de comienzo.
Para evitar que las tramas válidas subsiguientes del canal de fibra sean declaradas no válidas, debe
generarse el carácter K28.5 asociado con todos los conjuntos ordenados excepto EOF, suponiendo
una disparidad de funcionamiento de comienzo negativa. En el caso de que un error de transmisión
previo resulte en un EOF incorrecto para la disparidad de funcionamiento actual, se generará el
siguiente conjunto ordenado con RD− K28.5, lo que forzará que la disparidad de funcionamiento de
terminación sea negativa. Como resultado de esto, los errores de transmisión no provocarán la
propagación de un error en la disparidad de funcionamiento a través de las tramas.
Para el "transporte transparente" de las cabidas útiles de los canales de fibra, 10B_ERR se
recodificará en una palabra código con disparidad neutra 10B no reconocida, en función de que
disparidad de funcionamiento de comienzo sea negativa o positiva, es decir, (RD−) o (RD+), de
acuerdo con las reglas descritas en 8.1.1.1.
8.2.3.2 Cabida útil ESCON
Las reglas de disparidad de funcionamiento para ESCON se encuentran en ANSI INCITS 296,
Information Technology-Single-Byte Command Code Sets Connection (SBCON) Architecture,
sección 6.2.2. Como ESCON no define un código de error para sustituir las violaciones de código,

36 Rec. UIT-T G.7041/Y.1303 (08/2005)

en egreso, 10B_ERR se recodificará en una palabra código de disparidad neutra 10B no reconocida,
de que disparidad de funcionamiento de comienzo sea negativa o positiva, es decir, (RD−) o (RD+),
de acuerdo con las reglas descritas en 8.1.1.1.
8.2.3.3 Cabida útil FICON
Para fines de correspondencia a GFP transparente, las reglas de disparidad de funcionamiento para
FICON son idénticas a las especificadas para Canal para fibra en ANSI INCITS 230, Rev. 4.3.
8.2.3.4 Cabida útil Gigabit Ethernet
Las reglas de disparidad de funcionamiento para Gigabit Ethernet se encuentran en
IEEE 802.3-2002, sección 36.2.4. Se proporcionan dos codificaciones de Reposo indicadas
como /I1/ e /I2/. La primera /I/ a continuación de un paquete o de un conjunto ordenado de
configuración reestablece la disparidad de funcionamiento actual a un valor negativo. Todas
las /I/ subsiguientes son /I2/ para asegurar una disparidad de funcionamiento de terminación
negativa. Esta restricción permite que se inserten/supriman /I2/ simples para adaptación de
velocidad sin alterar la disparidad de funcionamiento de comienzo asociada con el grupo de código
subsiguiente a la /I2/ insertada o suprimida.
Con objeto de asegurar una la disparidad de funcionamiento de comienzo negativa para cada SOF,
todos los /I2/ en Reposo se deben generar con RD− K28.5, asegurando así una disparidad de
funcionamiento de comienzo negativa para el siguiente Reposo a SOF.
De conformidad con la sección 36.2.4.16 de IEEE 802.3-2002, los errores de disparidad de
funcionamiento detectados en el ingreso (y sustituidos por la palabra código 10B_ERR en el
proceso de codificación 64B/65B), deben sustituirse por la palabra de código /V/ (K30.7) que tiene
una disparidad correcta en el egreso. Opcionalmente, también es permisible recodificar una
10B_ERR recibida para formar una de las siguientes palabras clave de disparidad neutra 10B no
reconocidas, en función de la disparidad de funcionamiento de comienzo: 001111 0001 (RD−) u
110000 1110 (RD+). Asimismo, es admisible recodificar los 10B_ERR recibidos en una palabra
clave de disparidad neutra 10B no reconocida, en función de la disparidad de funcionamiento de
comienzo, (RD−) o (RD+), de conformidad con las reglas descritas en 8.1.1.1.
Obsérvese que dicha introducción opcional de códigos 10B_ERR sin correspondencia en un tren de
datos, sólo es adecuada si el sistema Ethernet adjunto no utiliza un registro de errores con fines de
mantenimiento del sistema.
8.2.3.5 Cabida útil DVB ASI
Los aspectos de disparidad de funcionamiento de la conversión de DVB ASI a GFP deberán
cumplir la norma para canales de fibra, que figura en ANSI INCITS 230, Fibre Channel-Physical
and Signalling Interface (FC-PH), Rev 4.3, sección 11. En el egreso, 10B_ERR será recodificado
en una palabra clave de disparidad neutra 10B no reconocida, en función de la disparidad de
funcionamiento de comienzo, (RD−) o (RD+), de conformidad con las reglas descritas en 8.1.1.1.

8.3 Aspectos de fallo de la señal específicos del cliente

Cuando la correspondencia GFP transparente detecte un fallo de la señal cliente en el ingreso, podrá
enviar una indicación de "fallo de la señal cliente" como se describe en 6.3.3. Las condiciones de
fallo de la señal cliente incluirán, como mínimo, la pérdida de la sincronización 8B/10B y, en
algunos casos, la pérdida de la señal. Otras indicaciones, que dependen de la implementación, de
una señal cliente fallida (por ejemplo la pérdida de reloj desde una interfaz entre circuitos
integrados) se pueden codificar como fallo de señal cliente.
Puesto que las señales clientes se proporcionan como trenes serie continuos de caracteres de 10 bits,
es necesario encontrar la alineación de la palabra de código. Hay caracteres especiales que
contienen el delimitador "coma" que proporcionan la información necesaria para llevar a cabo la

Rec. UIT-T G.7041/Y.1303 (08/2005) 37

alineación de la palabra código y mantenerla. Si bien todas las señales clientes 8B/10B emplean la
misma técnica de alineación de bits, las condiciones para detectar y liberar la pérdida de
sincronización 8B/10B son específicas del protocolo y se identifican en los siguientes puntos
específicos del protocolo.
Los fallos de la capa del servidor, en el propio proceso GFP, en el proceso de adaptación 64B/65B,
o en la red de transporte, pueden inducir una indicación CSF al proceso de adaptación de cliente.
Si el comienzo del CSF se produce dentro de una trama de datos cliente GFP, el resto de los
bloques 64B/65B de dicha trama GFP se rellenarán con códigos 10B_ERR. En el extremo remoto
dichos bloques restantes se decodificarán como errores.
En el extremo distante de una red de transporte, las señales cliente transportadas transparentemente
tienen que ser reconstruidas y entregadas de acuerdo con los requisitos de la interfaz física y de la
codificación específicos de cada protocolo. Las siguientes cláusulas específicas del cliente definen
la acción que se debe ejecutar en el egreso de la señal cliente en respuesta a una indicación de fallo
de señal cliente recibida del extremo remoto, o cualquier adaptación o defectos de transporte que
hagan imposible extraer una señal cliente.
8.3.1 Cabida útil del canal de fibra
8.3.1.1 Pérdida de luz (LOL) del canal de fibra
La pérdida de señal del canal de fibra es una opción que depende de la implementación. Cuando se
soporta, los requisitos aplicables de pérdida de luz y de detección de señal se indican en las
secciones 5.6, 6.2.3.2 y H.10 de ANSI INCITS 230, Fibre Channel-Physical and Signalling
Interface (FC-PH), Rev. 4.3.
Otras indicaciones dependientes de la implementación de una señal cliente fallida (por ejemplo,
pérdida de reloj de un SerDes) pueden codificarse como fallo de señal cliente.
8.3.1.2 Pérdida de sincronización 8B/10B de canal de fibra
Las condiciones del canal de fibra para declarar "dentro/fuera" de sincronización de la palabra
código 8B/10B se especifican en la sección 12.1 de ANSI INCITS 230.
8.3.1.3 Salida de canal de fibra debida a fallo de señal en el ingreso o en el transporte
Puesto que el objetivo de la correspondencia GFP transparente es transportar las señales cliente con
la mayor transparencia posible, no es conveniente comenzar procedimientos de inicialización del
enlace ni de recuperación del enlace en el egreso por fallo de la señal cliente o fallos en el
transporte. Se recomienda que el transmisor del canal de fibra en el egreso entregue continuamente
la decodificación de disparidad neutra para 10B_ERR, forzando la detección de la pérdida de
sincronización y la acción asociada en el receptor del canal de fibra en sentido descendente. Otra
posibilidad es que el transmisor en egreso genere la primitiva Not_Operational de acuerdo con la
sección 16.4.2 de ANSI INCITS 230.
Si persiste la condición CSF, el proceso de adaptación de cliente puede no transmitir nada, forzando
así la detección de LOS y la acción asociada en el receptor de Canal para fibra en sentido
descendente.
8.3.2 Cabida útil ESCON
8.3.2.1 Pérdida de señal (LOS) ESCON
Los requisitos de la detección de la pérdida de señal óptica se especifican en ANSI INCITS 296,
Information Technology-Single-Byte Command Code Sets Connection (SBCON) Architecture,
secciones 5.2 y 5.3, para las interfaces multimodo y monomodo, respectivamente.

38 Rec. UIT-T G.7041/Y.1303 (08/2005)

8.3.2.2 Pérdida de sincronización 8B/10B ESCON
Las condiciones ESCON para declarar que se está dentro o fuera de la sincronización de la palabra
de código 8B/10B se especifican en ANSI INCITS 296, sección 7.1.
8.3.2.3 Salida ESCON debida a fallo de señal en el ingreso o en el transporte
Dado que el objetivo de la correspondencia GFP transparente es transportar las señales cliente con
la mayor transparencia posible, no es adecuado iniciar procedimientos de inicialización del enlace
ni de recuperación del enlace en egreso por fallo de la señal cliente o fallos de transporte. Se
recomienda que el transmisor ESCON en el egreso entregue continuamente la decodificación de
disparidad neutra para 10B_ERR, forzando así la detección de la pérdida de sincronización y la
acción asociada en el receptor ESCON en sentido hacia el destino. Como otra posibilidad, el
transmisor en egreso puede generar la secuencia Not-operational de conformidad con la
sección 7.4.2 de ANSI INCITS 296.
Si persiste la condición CSF, el proceso de adaptación de cliente puede no transmitir nada, forzando
así la detección de LOS y la acción asociada en el receptor ESCON en sentido descendente.
8.3.3 Cabida útil FICON
Los requisitos del tratamiento de SCF para FICON que son idénticos a los requisitos del canal de
fibra, especificados en ANSI INCITS 230, Rev. 4.3.
8.3.4 Cabida útil de Gigabit Ethernet dúplex
8.3.4.1 Pérdida de señal Gigabit Ethernet
Los requisitos correspondientes a la detección de señal dependiente de los medios físicos (PMD,
physical media dependent) de Gigabit Ethernet se especifican en las secciones 38.2.4 y 39.2.3 de
IEEE 802.3-2002 para las interfaces de fibra y de cobre, respectivamente.
8.3.4.2 Pérdida de sincronización 8B/10B de Gigabit Ethernet
Las condiciones de Gigabit Ethernet para declarar que se está dentro o fuera de la sincronización de
la palabra de código 8B/10B se especifican en IEEE 802.3-2002, sección 36.2.5.2.6 y figura 36-9.
8.3.4.3 Salida de Gigabit Ethernet debida a fallo de señal en el ingreso o en el transporte
Puesto que el objetivo de la correspondencia GFP transparente es transportar las señales cliente con
la mayor transparencia posible, no es adecuado iniciar los procedimientos de inicialización del
enlace o de recuperación del enlace en egreso por fallo de la señal cliente o fallos de transporte. Se
recomienda que el transmisor GbE en el egreso entregue continuamente el conjunto ordenado /V/ de
acuerdo con la sección 36.2.4.16 de IEEE 802.3-2002, forzando así la detección de la pérdida de
sincronización y la acción asociada en el receptor GbE en el sentido de transmisión hacia el destino.
Si persiste la condición fallo de señal cliente (CSF), el proceso de adaptación de cliente puede no
transmitir nada, forzando así la detección de LOS y la acción asociada en el receptor GbE en
sentido descendente.
8.3.5 Cabida útil DVB ASI
8.3.5.1 Pérdida de luz (LOL) DVB ASI
En referencia a las normas Canal para fibra, la pérdida de señal DVB ASI es una opción que es
función de la implementación. Cuando está soportada, los requisitos aplicables de pérdida de luz y
detección de señal son los que figuran en las secciones 5.6, 6.2.3.2 y H.10 de ANSI INCITS 230,
Fibre Channel-Physical and Signalling Interface (FC-PH), Rev 4.3.
Otras indicaciones función de la implementación de una señal cliente fallida (por ejemplo, pérdida
de reloj de un SerDes) pueden codificarse como fallo de señal cliente.

Rec. UIT-T G.7041/Y.1303 (08/2005) 39

8.3.5.2 Pérdida de sincronización 8B/10B DVB ASI
De acuerdo con el apéndice B de ETSI EN 50083-9, la sincronización de la palabra código DVB
ASI se realizará cuando se reciban dos caracteres /K28.5/ con la misma alineación durante 5
caracteres recibidos consecutivamente. ETSI EN 50083-9 no especifica criterios para declarar
pérdida de sincronización de palabra de código. Los criterios Canal para fibra pueden no ser
aplicables dado que la sincronización y transmisión de palabra código DVB ASI está basada en
caracteres, en lugar de estarlo la transmisión de palabras de cuatro caracteres. En ausencia de
directrices de ETSI EN 50083-9, los criterios de pérdida de sincronización de palabra código basada
en caracteres ESCON/SBCON deben ser los especificados en ANSI INCITS 296, sección 7.1.
8.3.5.3 Salida DVB ASI debida a fallo de señal en el egreso o en el transporte
El transmisor DVB ASI en el egreso debe generar continuamente como salida la decodificación de
disparidad neutra para 10B_ERR, forzando así la detección de pérdida de señal y cualquier acción
asociada en el receptor DVB ASI en sentido descendente. Si persiste la condición de fallo de señal
cliente (CSF), el proceso de adaptación de cliente puede no transmitir nada, forzando así la
detección de LOS y la acción asociada en el receptor DVB ASI en sentido descendente.

8.4 Conversión transparente a máxima velocidad síncrona de clientes 8B/10B en GFP

La conversión transparente de clientes codificados mediante bloques 8B/10B puede realizarse
mediante una conversión síncrona (a máxima velocidad) de todos los caracteres clientes recibidos.
Esta conversión transparente utiliza la correspondencia común basada en caracteres descrita en 8.1,
así como los procesos específicos de cliente descritos en 8.2.3 y 8.3. Además, los requisitos
específicos de cliente descritos en las subcláusulas siguientes se aplican antes de la conversión y
encapsulado (en sentido de ingreso), y después de anular la conversión, extraer los bloques
64B/65B y decodificarlos en códigos bloque 8B/10B (en sentido de egreso).
8.4.1 Adaptación de velocidad en los códigos 64B/65B
En el ingreso, la adaptación de velocidad a la velocidad de datos de la cabida útil de salida se
produce en el proceso de codificación 64B/65B. Si no hay una palabra de código 8B/10B disponible
para que el dispositivo de conversión la recodifique en un código de bloque 64B/65B, el dispositivo
de conversión inserta una 65B_PAD como se describe en 8.1.1.2. Esencialmente, esta 65B_PAD es
un reposo no de cliente que se utiliza para rellenar bloques 64/65B para fines de adaptación de
velocidad. En el egreso, el dispositivo de anulación de correspondencia suprime estas señales
reposo no clientes. Como se utilizan tramas GFP de longitud fija, y las tramas pueden rellenarse con
65B_PAD para adaptación de velocidad, no hay necesidad de almacenar en memoria intermedia
una trama GFP completa antes de insertarla en la cabida útil de la señal de transporte saliente, con
lo que se reduce el almacenamiento intermedio y el retardo en el proceso de correspondencia.
8.4.1.1 Procedimientos de adaptación de velocidad en el egreso
Existen dos soluciones para la generación del reloj de la interfaz de datos de egreso de cliente en el
proceso de adaptación de sumidero específico de cliente GFP. Una solución consiste en adaptar la
señal cliente a una fuente de reloj que es local al proceso de adaptación de sumidero GFP. La otra
consiste en generar el reloj de egreso de la señal cliente derivándolo de la señal GFP recibida y del
reloj de transporte.
Si ocurre un fallo ya sea en la señal cliente de ingreso o durante el transporte SDH/OTN, se requiere
aún un reloj de referencia local específico del protocolo en el punto de egreso de los datos cliente si
el cliente espera que una señal de fallo de enlace de velocidad de cliente sustituya al cliente fallido.

40 Rec. UIT-T G.7041/Y.1303 (08/2005)

8.4.1.1.1 Adaptación de velocidad a un reloj de referencia local
Las señales cliente 8B/10B soportadas actualmente especifican frecuencias operativas con
requisitos de desplazamiento de reloj de ±100 ppm a ±200 ppm, los cuales son considerablemente
menos exigentes en comparación con SDH u OTN. Cada una de estas señales cliente está diseñada
para permitir una adaptación de velocidad a un reloj de referencia local, ya sea en repetidores o en
el extremo remoto, mediante la inserción o supresión de Reposo de cliente (o una palabra de
relleno). Para facilitar esta adaptación de velocidad, cada una de estas señales cliente impone reglas
mínimas de intervalo interpaquete (IPG), las cuales especifican el número mínimo de palabras
código de reposo que deben insertarse entre paquetes de datos. Cada una de estas señales cliente
especifica también el tamaño máximo del paquete de datos. Se han establecido reglas mínimas de
IPG para asegurar que cuando se requiere adaptación de velocidad a un reloj local, aun en la
condición de caso más desfavorable en la que un reloj rápido en la entrada y un reloj lento en la
salida requieren la supresión de algunos Reposos IPG, permanecerá un IPG suficiente entre los
paquetes para una delimitación correcta de las tramas cliente.
Este esquema puede utilizarse también cuando se reconstruyen datos de cliente con conversión
transparente en el egreso. Con esta solución, se suministra un reloj de referencia local en el proceso
de adaptación de sumidero GFP. Conforme se anula la conversión de datos cliente de las tramas
GFP y dichos datos se recodifican en palabras código 8B/10B se adaptan en velocidad al reloj de
referencia local a través de la inserción/supresión de Reposo. Se requiere un procesamiento
específico del cliente para reconocer las oportunidades válidas para insertar/suprimir palabras de
código de reposo, generar códigos de reposo apropiados, e insertar tales códigos en el tren de bits de
egreso. Un ejemplo de un parámetro específico del cliente es el número mínimo y el número
máximo de Reposos que se permite insertar o suprimir.
Incluso en los enlaces que contienen múltiples repetidores, si todos los relojes "locales" satisfacen
los requisitos de exactitud para el protocolo específico, se producirán suficientes oportunidades para
la inserción o supresión de reposos, ya que los desplazamientos de temporización compuestos a
través de los repetidores en cascada no pueden exceder los requisitos de desplazamiento de reloj
para el caso más desfavorable.
Con este enfoque, las características de temporización tales como la fluctuación de fase y la
fluctuación lenta de fase de la señal cliente reconstruida dependen en primer lugar de la calidad del
reloj de referencia local. El reloj de referencia local es específico de la velocidad del protocolo (por
ejemplo Gigabit Ethernet, Canal para fibra, y ESCON no comparten frecuencias comunes).
8.4.1.1.2 Adaptación de la velocidad a partir de la señal cliente transportada
En el ingreso, las señales cliente se proporcionan a una velocidad de reloj uniforme específica del
protocolo. Si bien pueden existir espaciamientos en los paquetes mismos de datos cliente, éstos se
rellenan con intervalos interpaquete (IPG) a una velocidad de reloj constante. La conversión
transparente preserva todos los datos del cliente, el control y la información IPG cuando se
recodifican utilizando 64B/65B (suponiendo que no hay pérdida de señal cliente ni pérdida de
sincronización de caracteres). Sin embargo, los datos recodificados se convierten entonces en
tramas GFP con relleno 65B_PAD para adaptar su velocidad al canal de cabida útil de transporte de
mayor anchura de banda. También se pueden insertar periódicamente o cuando convenga tramas de
gestión de cliente o de control GFP entre tramas de datos clientes GFP. Las tramas de transporte
añaden su propia tara (tara de sección y de trayecto más octetos de relleno fijo en el caso de SDH).
No se mantiene alineación alguna entre los datos del cliente, los octetos o bloques de relleno, las
tramas GFP y la tara de transporte.

Rec. UIT-T G.7041/Y.1303 (08/2005) 41

En el egreso, es previsible que la recuperación de reloj requiera un dispositivo FIFO y un
desincronizador, donde el desincronizador requerirá un reloj de referencia, un bucle PLL, y un
filtro. La temporización de reloj recuperada dependerá de alguna versión filtrada del nivel de
llenado del dispositivo FIFO. El propio dispositivo FIFO estaría sometido a cambios de cierta
consideración en su nivel en condiciones normales de funcionamiento debido a la aparición de
grandes bloques de tara de sección/transporte, tara de trama GFP, y tramas de gestión de cliente
GFP. En las condiciones más desfavorables, es posible que todos los mecanismos de "intervalo" de
datos cliente estén alineados en un bloque contiguo de "no datos cliente". La naturaleza
relativamente aperiódica de algunos de los intervalos combinada con la tolerancia de frecuencia del
reloj de fuente, relativamente grande, complica el diseño del dispositivo FIFO y del bucle PLL.
La ventaja de esta solución de desincronizador es que no se requiere un conocimiento específico del
protocolo para recuperar el reloj de cliente en el egreso.
Las características de temporización de la fluctuación de fase y de la fluctuación lenta de fase de la
señal cliente reconstruida dependen en primer lugar del diseño del sistema de recuperación de reloj.
Con un diseño más complejo se podrá soportar una amplia gama de velocidades de cliente con un
solo diseño.
8.4.1.2 Aspectos de la adaptación de velocidad específicos del cliente
En el egreso, las señales cliente transportadas transparentemente deben ser reconstruidas y
presentadas a la salida de una manera que satisfaga los requisitos de interfaz física específicos de
cada protocolo. Independientemente del enfoque de temporización a la salida para el cliente
seleccionado, se deben satisfacer los requisitos de temporización específicos del protocolo, como se
define en las normas aplicables a cada protocolo cliente. Las siguientes cláusulas identifican los
requisitos aplicables esenciales, aunque se pueden aplicar otros requisitos específicos del protocolo.
8.4.1.2.1 Cabida útil del canal de fibra
La máxima velocidad de datos de salida del canal de fibra (después de la codificación 8B/10B)
deberá ser de 531,25; 1062,5; 2125 ó 4250 Mbit/s ± 100 ppm, como se especifica en
ANSI INCITS 230, Fibre Channel-Physical and Signalling Interface (FC-PH) Rev. 4.3,
sección 5.1. Los requisitos de temporización de la señal de salida se especifican con mayor detalle
en ANSI INCITS 230, secciones 6.1.1 (Single-mode optical output interface), 6.2.1 (Multi-mode
optical output interface), y 7 (Electrical cable interface). Las señales de salida serán generadas
normalmente con un mínimo de seis señales primitivas (Reposos y R_RDY) entre tramas, como se
especifica en ANSI INCITS 230, sección 17.1. Si la adaptación de velocidad se efectúa utilizando
inserción/supresión de Reposos del canal de fibra, la adaptación de velocidad se aplicará de tal
manera que el receptor de destino obtenga al menos dos Reposos precediendo a cada trama, como
se especifica en ANSI INCITS 230, sección 17.1.
Puede requerirse también la adaptación de velocidad cuando se recibe un tren continuo de
secuencias primitivas de canal de fibra; las secuencias primitivas se definen en el cuadro 26 de
ANSI INCITS 230. Puesto que se requiere la recepción de un mínimo de tres secuencias primitivas
idénticas consecutivas antes de que se reconozca la secuencia (de acuerdo con la sección 16.4.1 de
ANSI INCITS 230), la adaptación de velocidad mediante la inserción de una réplica de la secuencia
recibida de cuatro caracteres, o la supresión de una secuencia recibida, sólo se producirá después de
que se hayan recibido y retransmitido tres secuencias idénticas consecutivas.
En función de la implementación, podría generarse en el egreso un tren continuo de caracteres de
disparidad neutra 10B_ERR, aunque la adaptación de velocidad se requiere aún en esta situación.
En este caso, la adaptación de velocidad se puede efectuar suprimiendo o insertando un carácter de
disparidad neutra 10B_ERR después de que se hayan recibido y retransmitido 12 caracteres
10B_ERR consecutivos.

42 Rec. UIT-T G.7041/Y.1303 (08/2005)

8.4.1.2.2 Cabida útil ESCON
La velocidad de datos de salida de ESCON (después de la codificación 8B/10B) deberá ser de
200 Mbit/s ± 0,04 Mbit/s, como se especifica en ANSI INCITS 296, Information Technology-Single
Byte Command Code Sets Connection (SBCON) Architecture, sección 5.1.2. Los requisitos de
temporización de la señal de salida se especifican con mayor detalle en ANSI INCITS 296,
secciones 5.2.1 (Multi-mode output interface) y 5.3.1 (Single-mode output interface). Las señales de
salida deberán generarse normalmente con un mínimo de cuatro caracteres de reposo (K28.5) entre
tramas de datos, como se especifica en ANSI INCITS 296, sección 6.3. De conformidad con las
reglas de ANSI INCITS 296, sección 7.2, si la adaptación de velocidad se efectúa mediante la
inserción/supresión de Reposo ESCON, dicha adaptación está limitada a un evento de
inserción/supresión entre dos tramas cualesquiera, estando formado dicho evento de
inserción/supresión por la adición o supresión de uno o dos caracteres Reposo. Sin embargo, un
único evento de inserción/supresión entre tramas puede no proporcionar la suficiente capacidad de
corrección de velocidad cuando el intervalo entre tramas es suficientemente largo. Por lo tanto, con
fines de adaptación en egreso de GFP-T, se permite un número cualquiera de eventos de
inserción/supresión entre tramas, supuesto que dichos eventos no ocurren, en promedio, más de una
vez cada 2500 caracteres, y no dejan menos de dos Reposos entre tramas. Se puede requerir también
la adaptación de velocidad cuando se recibe un tren continuo de secuencias de conjuntos ordenados;
las secuencias de conjuntos ordenados se definen en el cuadro 15 de ANSI INCITS 296. Como se
requiere la recepción de un mínimo de ocho secuencias consecutivas antes de que se reconozca la
secuencia (según la sección 6.3 de ANSI INCITS 296), la adaptación de velocidad mediante la
inserción de una réplica de la secuencia recibida de dos caracteres, o la supresión de una secuencia
recibida, sólo se producirá después de que se hayan recibido y retransmitido ocho secuencias
idénticas consecutivas.
En función de la implementación, se podría generar en el egreso un tren continuo de caracteres de
disparidad neutra 10B_ERR, aunque la adaptación de velocidad se requiere aún en esta situación.
En este caso, la adaptación de velocidad se puede efectuar suprimiendo o insertando un carácter de
disparidad neutra 10B_ERR después de que se hayan recibido y retransmitido 12 caracteres
10B_ERR consecutivos.
8.4.1.2.3 Cabida útil FICON
Los requisitos de temporización para FICON son los mismos que los especificados para el canal de
fibra en ANSI INCITS 230, Rev. 4.3.
8.4.1.2.4 Cabida útil Gigabit Ethernet en dúplex
La velocidad de datos de salida de Gigabit Ethernet (GbE) (después de la codificación 8B/10B) será
1250 Mbit/s ± 100 ppm, como se especifica en IEEE 802.3. Los requisitos de temporización de la
señal de salida se especifican con mayor detalle en IEEE 802.3, secciones 38.5 y 38.6
(1000BASE-LX optical fibre interfaces) y 39.3.1 y 39.3.3 (1000BASE-CX short-haul copper
interface). Las señales de salida deberán generarse normalmente con un IPG mínimo de 12 octetos,
de acuerdo con IEEE 802.3, sección 4.4.2.3. Los caracteres Reposo de GbE están formados por
dos octetos, como se define en IEEE 802.3, sección 36.2.4.12. Si la adaptación de velocidad se
efectúa mediante inserción/supresión de Reposo GbE en modo dúplex, puede suprimirse cualquier
número de /I2/ en cualquier IPG, de forma que si dicha supresión no dé como resultado la ausencia
de /I/ y que queden no menos de 8 octetos incluidos /T/, /R/, e /I/ entre las tramas, tal como exige
una correcta delimitación de trama de conformidad con IEEE 802.3, figuras 36-7a y 36-7b. En
cualquier IPG puede añadirse un número cualquiera de /I2/. Se puede requerir también la
adaptación de velocidad cuando se recibe un tren continuo de conjuntos ordenados de configuración
de ocho caracteres (constituido por /C1/C2/ alternos). Puesto que hay que recibir un mínimo de tres
conjuntos ordenados de configuración /C1/C2/ consecutivos antes de que se reconozca el conjunto
de configuración, la adaptación de velocidad mediante la inserción de una réplica de la

Rec. UIT-T G.7041/Y.1303 (08/2005) 43

secuencia /C1/C2/ recibida, o la supresión de una secuencia /C1/C2/ recibida sólo se producirá
después de que se hayan recibido y retransmitido tres secuencias /C1/C2/ idénticas consecutivas. En
función de la implementación, se podría generar en egreso un tren continuo de caracteres de
disparidad neutra 10B_ERR, o de error de transmisión (/V/) lo que requiere aún adaptación de
velocidad. En este caso, la adaptación de velocidad se puede efectuar suprimiendo o replicando un
carácter 10B_ERR o /V/ después de que se hayan recibido y retransmitido 12 caracteres 10B_ERR
o /V/ consecutivos.
8.4.1.2.5 Cabida útil DVB ASI
La velocidad de datos de salida DVB ASI (después de la codificación 8B/10B) deberá ser de
270 Mbit/s ± 100ppm, tal como se especifica en el apéndice B de ETSI EN 50083-9.
Adicionalmente, los requisitos de la temporización de la señal de salida se especifican haciendo
referencia a la especificación del canal de fibra incluida en ANSI INCITS 230.
Entre paquetes MPEG debe existir un mínimo de dos caracteres /K28.5/. Entre paquetes o dentro de
los mismos, pueden existir caracteres /K28.5/ adicionales de adaptación de velocidad. Si la
adaptación de velocidad se realiza mediante la eliminación de /K28.5/, la adaptación de velocidad
es tal que el destino receptor recibe al menos dos caracteres /K28.5/ precediendo a cada trama, tal
como se especifica en el apéndice B de ETSI EN 50083-9. Si la adaptación de velocidad requiere la
inserción de caracteres /K28.5/, éstos pueden insertarse entre o dentro de los paquetes MPEG.
En función de la implementación, se podría recibir o generar en el egreso un tren continuo de
caracteres de disparidad neutra 10B_ERR (por ejemplo, en respuesta a un fallo de señal cliente
recibido). En este caso, la adaptación de velocidad se puede efectuar suprimiendo o insertando un
carácter de disparidad neutra 10B_ERR después de que se hayan recibido y retransmitido
12 caracteres 10B_ERR consecutivos.

8.5 Conversión asíncrona (a velocidad máxima o a una velocidad inferior) de clientes

8B/10B en GFP
El transporte a una velocidad inferior de señales cliente codificadas mediante bloques 8B/10B
puede realizarse por medio de una conversión asíncrona (a máxima velocidad o a una velocidad
inferior) de los caracteres cliente recibidos. La conversión transparente asíncrona emplea una
correspondencia basada en caracteres comunes descrita en 8.1, así como los procesos específicos de
cliente de 8.2.3 y 8.3. Sin embargo, la conversión asíncrona es típicamente una correspondencia
menos transparente basada en caracteres, en la que el procesamiento específico del cliente (en
ingreso) suprime caracteres de reposo de clientes del tren de palabras clave. Puede aplicarse control
de flujo para asegurar el transporte sin pérdidas de la señal cliente sobre trayectos de transporte con
una anchura de banda inferior a la de las señales clientes a máxima velocidad. Los requisitos
específicos de cliente descritos en la subsección siguiente se aplican antes de la correspondencia y
el encapsulado (en sentido de ingreso) y tras la anulación de la correspondencia, extracción de
bloques 64B/65B y su decodificación en códigos boque 8B/10B (en sentido de egreso).
8.5.1 Aspectos específicos del canal de fibra para la conversión GFP-T asíncrona
Los aspectos específicos del canal de fibra para la correspondencia GFP-T asíncrona requieren
estudios adicionales.

44 Rec. UIT-T G.7041/Y.1303 (08/2005)

 Apéndice I

Ejemplos de modelos funcionales de aplicaciones GFP

En este apéndice se presentan algunos ejemplos de modelos funcionales de aplicaciones GFP. En

ausencia de arquitecturas de red de capa para redes de capas de datos (por ejemplo, IP e Ethernet),
los modelos se presentan exclusivamente para fines de información.
GFP se puede desplegar en elementos de red de transporte (por ejemplo, SDH), y en elementos de
redes de datos (por ejemplo, IP, Ethernet).
En el primer caso, se proporciona una interfaz física de datos (de tipo Ethernet o red de área de
almacenamiento) como un puerto de interfaz afluente en el elemento de red de transporte. Si la
señal física de datos es una señal codificada 8B/10B, se puede transportar a través de la red de
transporte como un tren transparente utilizando la correspondencia GFP-T (figura I.1). Si sólo una
parte de la anchura de banda de la interfaz física transporta tráfico, y este tráfico es el único que
debe ser transportado por la red de transporte, se termina la señal de la interfaz física de datos y se
extraen las PDU de datos para reenviarlas mediante correspondencia GFP-F mediante una señal a
VC-m-Xv, VC-n, VC-n-Xc, o VC-n-Xv (figura I.2).
En el segundo caso, el procedimiento GFP se realiza entre la textura de encaminador IP [Ethernet
Switch] y, por ejemplo, funciones de puerto de interfaz STM-N (figuras I.3 y I.4).

Figura I.1/G.7041/Y.1303 – Puerto de interfaz afluente FC/ES/FI/GE

con conversión GFP-T en elemento de red SDH a velocidad completa

Rec. UIT-T G.7041/Y.1303 (08/2005) 45

 Figura I.2/G.7041/Y.1303 – Puerto de interfaz afluente Ethernet
con conversión GFP-F en elemento de red SDH

Figura I.3/G.7041/Y.1303 – Puerto VC-n/VC-n-Xv/VC-n-Xc en encaminador IP,

o función de encaminador IP insertado en equipo híbrido SDH/IP

46 Rec. UIT-T G.7041/Y.1303 (08/2005)

Figura I.4/G.7041/Y.1303 – Puerto VC-n-Xv en conmutador Ethernet, o función
de conmutador Ethernet insertado en equipo híbrido SDH/Ethernet

Extracción/delimitación n FC-BBW_SONET Extracción FC MAC

FC MAC (a partir de FC-1) FC-1/FC-2 / FC-2 (de FC-BBW_SONET)

FC-1 FC-BBW
PHY-FC (FC-1)
Terminación FC-BBW_SONET
Procesamiento de control de enlace

– Tramas FC-BBW_SONET
– Codificación/decodificación Sn[-X]/FC-BBW encapsuladas GFP-F
de línea FC-PHY PHY-FC/FC-1 (GFP-F) – Tren de tramas GFP convertido
– Recuperación de reloj/datos en VC-n/VC-n-xV

PHY-FC (FC-0) PHY-FC Sn[-X]

Trayecto de terminación
por ejemplo 1G, 2G, 4G
VC-n/VC-n-Xv
y 10G FC

Señal física Señal VC-n

o X señales VC-n

Figura I.5/G.7041/Y.1303 – Puerto de interfaz afluente canal para fibra

con conversión FC-BBW_SONET y GFP-F en elemento de red SDH

Rec. UIT-T G.7041/Y.1303 (08/2005) 47

 Apéndice II

Ejemplos de tipos de cabida útil GFP

Cuadro II.1/G.704/Y.1303 − Tipos de cabida útil GFP

Identificador Identificador Identificador de Identificador
Longitud de
de tipo de de FCS de la encabezamiento de la cabida
Tipo encabezamientos
cabida útil cabida útil de extensión útil de usuario Cabida útil de de extensión
(Binario) (Binario) (Binario) (Binario) la trama GFP
Bits de tipo Bit de tipo Bits de tipo Bits de tipo (número de
(HEX)
<15:13> <12> <11:8> <7:0> octetos)
000 0 xxxx 0000 0000 0x00 Reservado
000 1 xxxx 0000 0000 1x00 Reservado
Ethernet con
encabezamiento de
000 0 0000 0000 0001 0001 0
extensión nulo y sin
FCS de la cabida útil
PPP con
encabezamiento de
000 0 0000 0000 0010 0002 0
extensión nulo y sin
FCS de la cabida útil
Ethernet con
encabezamiento de
000 0 0001 0000 0001 0101 4
extensión lineal y sin
FCS de la cabida útil
PPP con
encabezamiento de
000 0 0001 0000 0010 0102 4
extensión lineal y sin
FCS de la cabida útil
Ethernet con
encabezamiento de
000 0 0010 0000 0001 0201 extensión en anillo y 18
sin FCS de la cabida
útil
PPP con
encabezamiento de
000 0 0010 0000 0010 0202 extensión en anillo y 18
sin FCS de la cabida
útil
Canal para fibra
transparente con
000 0 0000 0000 0011 0003 encabezamiento de 0
extensión nulo y sin
FCS de la cabida útil
FICON transparente
con encabezamiento
000 0 0000 0000 0100 0004 de extensión nulo y 0
sin FCS de la cabida
útil
ESCON transparente
con encabezamiento
000 0 0000 0000 0101 0005 de extensión nulo y 0
sin FCS de la cabida
útil

48 Rec. UIT-T G.7041/Y.1303 (08/2005)

 Cuadro II.1/G.704/Y.1303 − Tipos de cabida útil GFP
Identificador Identificador Identificador de Identificador
Longitud de
de tipo de de FCS de la encabezamiento de la cabida
Tipo encabezamientos
cabida útil cabida útil de extensión útil de usuario Cabida útil de de extensión
(Binario) (Binario) (Binario) (Binario) la trama GFP
Bits de tipo Bit de tipo Bits de tipo Bits de tipo (número de
(HEX)
<15:13> <12> <11:8> <7:0> octetos)
Gb Ethernet
transparente con
000 0 0000 0000 0110 0006 encabezamiento de 0
extensión nulo y sin
FCS de la cabida útil
1xx x xxxx xxxx xxxx – Reservado –
x1x x xxxx xxxx xxxx – Reservado –
xx1 x xxxx xxxx xxxx – Reservado –

Apéndice III

Ejemplo de trama GFP que ilustra el orden

de transmisión y el cálculo de CRC
III.1 Ejemplo práctico de trama GFP-F
Transmisión:
User_data Æ adaptación GFP_source Æ aleatorización y DC_balance Æ SDH
Recepción:
SDH Æ un_DC_balance y desaleatorización Æ desencapsulado de GFP_sink Æ datos cliente
En el siguiente ejemplo práctico se presenta la encapsulación de una trama Ethernet de 64 octetos
con encabezamiento lineal y FCS, antes del equilibrado de corriente continua y aleatorización
autosincronizada. Se ha establecido la correspondencia de los octetos de datos Ethernet con un
octeto GFP con un orden de transmisión de bits inverso respecto al orden de transmisión de bits
Ethernet (bit 0 en IEEE 802.3, cláusula 3 corresponde al bit 8 del octeto GFP, y el bit 7 de
IEEE 802.3, cláusula 3 corresponde al bit 1 del octeto GFP). Los valores hexadecimales de este
ejemplo se presentan de forma que el bit más significativo (MSB) está a la izquierda, y el bit menos
significativo (LSB) está a la derecha.

Octeto Campo Valor(hex) Observaciones

1 PLI[15:8] 00 ; PLI = longitud { Encabezamiento cabida útil + campo
de información de la cabida útil +FCS
de la cabida útil }
2 PLI[7:0] 4C ; = 8 + 64 + 4 = 76 bytes
3 cHEC[15:8] 89 ;
4 cHEC[7:0] 48 ;
5 TYPE[15:8] 11 ; [15:13]='000' (datos del cliente)
6 TYPE[7:0] 01 ; [12] ='1' (FCS de la cabida útil habilitada)

Rec. UIT-T G.7041/Y.1303 (08/2005) 49

Octeto Campo Valor(hex) Observaciones
7 tHEC[15:8] 20 ; [11:8] ='0001' (encabezamiento lineal)
8 tHEC[7:0] 63 ; [7:0] ='00000001' (Ethernet)
9 EHDR[15:8] 80 ; CID[07:00]=0x8000 valor es justo un ejemplo
10 EHDR[7:0] 00 ; SPARE[7:0]
11 eHEC[15:8] 1B ; eHEC calculado sobre CID,SPARE
12 eHEC[7:0] 98 ; Fin de encabezamiento de la extensión
13 DATA FF ; 1d Ethernet DA=0xFFFFFFFFFFFF
14 DATA FF ; 2d
15 DATA FF ; 3d
16 DATA FF ; 4d
17 DATA FF ; 5d
18 DATA FF ; 6d
19 DATA 06 ; 7d Ethernet SA=0x060504030201
20 DATA 05 ; 8d
21 DATA 04 ; 9d
22 DATA 03 ; 10d
23 DATA 02 ; 11d
24 DATA 01 ; 12d
25 DATA 00 ; 13d Ethernet TIPO/LONGITUD
26 DATA 2E ; 14d
27 DATA 00 ; 15d Cabida útil de Ethernet
28 DATA 01 ; 16d
29 DATA 02 ; 17d
30 DATA 03 ; 18d
31 DATA 04 ; 19d
32 DATA 05 ; 20d
33 DATA 06 ; 21d
34 DATA 07 ; 22d
35 DATA 08 ; 23d
36 DATA 09 ; 24d
37 DATA 0A ; 25d
38 DATA 0B ; 26d
39 DATA 0C ; 27d
40 DATA 0D ; 28d
41 DATA 0E ; 29d
42 DATA 0F ; 30d
43 DATA 10 ; 31d
44 DATA 11 ; 32d
45 DATA 12 ; 33d
46 DATA 13 ; 34d
47 DATA 14 ; 35d
48 DATA 15 ; 36d

50 Rec. UIT-T G.7041/Y.1303 (08/2005)

Octeto Campo Valor(hex) Observaciones
49 DATA 16 ; 37d
50 DATA 17 ; 38d
51 DATA 18 ; 39d
52 DATA 19 ; 40d
53 DATA 1A ; 41d
54 DATA 1B ; 42d
55 DATA 1C ; 43d
56 DATA 1D ; 44d
57 DATA 1E ; 45d
58 DATA 1F ; 46d
59 DATA 20 ; 47d
60 DATA 21 ; 48d
61 DATA 22 ; 49d
62 DATA 23 ; 50d
63 DATA 24 ; 51d
64 DATA 25 ; 52d
65 DATA 26 ; 53d
66 DATA 27 ; 54d
67 DATA 28 ; 55d
68 DATA 29 ; 56d
69 DATA 2A ; 57d
70 DATA 2B ; 58d
71 DATA 2C ; 59d
72 DATA 2D ; 60d
73 DATA DE ; 61d FCS de Ethernet calculada sobre 60 bytes
74 DATA E1 ; 62d
75 DATA 90 ; 63d
76 DATA D0 ; 64d
77 FCS[31:24] 56 ; Primer byte de la FCS opcional de la cabida útil GFP
78 FCS[23:16] CF ; Cubre sólo el campo de información de la cabida útil,
79 FCS[15:8] 2B ; excluye el encabezamiento de la extensión (o sea 64 bytes)
80 FCS[7:0] B0 ; Último byte de la FCS GFP opcional.

El encabezamiento principal se somete a la operación "XOR" con el código Barker DC,

manteniéndose el resto de la trama GFP sin modificación.
Octeto Campo Valor(hex) Observaciones
1 PLI[15:8] B6 ; 00 xor B6
2 PLI[7:0] E7 ; 4C xor AB
3 cHEC[15:8] B8 ; 89 xor 31
4 cHEC[7:0] A8 ; 48 xor E0
5 ...

Rec. UIT-T G.7041/Y.1303 (08/2005) 51

El ejemplo siguiente muestra el cálculo de la cHEC para PLI[15:0] = 0x004C. El polinomio es
G(x) = x16 + x12 + x5 + 1. El PLI se introduce en la calculadora CRC-16 con PLI[15:8] primero, y
luego PLI[7:0], empezando cada octeto por el bit más significativo.

x15 ... x0
0000000000000000 ← CRC-16 estado inicial
Bit de entrada 1 0001000000100001 ← CRC-16 después del bit de entrada
0 0010000001000010
0 0100000010000100
1 1001000100101001
1 0010001001010010
0 0100010010100100
0 1000100101001000
La transmisión de CRC-16 empezando por x15 produce los octetos GFP cHEC[15:0] = 0x8948.
La trama GFP se introduce en el aleatorizador x43 + 1 en el orden de bits de la red (el bit más
significativo primero). Empezando por el primer octeto del campo TYPE (TIPO) (el
encabezamiento fundamental no se aleatoriza):
Bit #1 TYPE[15]
Bit #2 TYPE[14]
Bit #3 TYPE[13]
...

III.2 Ejemplo examinado del cálculo de la CRC de un superbloque GFP-T

La presente cláusula es un ejemplo práctico de cálculo de la CRC-16 de un superbloque GFP-T. Por
ejemplo, el primer octeto de este superbloque (octeto 1,1) contiene el valor 80 hex (es decir, un 1 en
la posición del bit más significativo (MSB)), y todos los demás octetos del superbloque, incluido el
octeto L-bit, son 0. El valor CRC-16 resultante será 1001 1010 1010 0010 (9AA2 hex) en los bits
CRC1-CRC16, respectivamente.

52 Rec. UIT-T G.7041/Y.1303 (08/2005)

 Apéndice IV

Número de superbloques utilizados en el GFP transparente

IV.1 Introducción
En el GFP-T hay un número entero (N) de superbloques de 536 bits en una trama de datos cliente.
El valor de N debe elegirse de forma que el rendimiento de los bits de datos cliente relativo a los
bits de tara de la trama GFP proporcione una anchura de banda suficiente para transportar la señal
de datos cliente. El valor de N puede elegirse de forma que proporcione suficiente anchura de banda
"de reserva" adicional para el transporte de las tramas de gestión del cliente (CMF, client
management frames). Los valores mínimos de N se presentan aquí como función de los diversos
bits de tara y del número de tramas de gestión de cliente que se pueden transmitir entre tramas de
datos del cliente GFP-T sucesivas.

IV.2 Cálculo de la anchura de banda "de reserva"

La anchura de banda de reserva, SBW, de un canal GFP-T se define de la forma siguiente:
SBW = (velocidad binaria mínima para transportar bits clientes en el canal) – (velocidad
binaria de datos cliente)
= (velocidad binaria de canal mínima)(relación entre bits de datos cliente y número total
de bits) – (velocidad binaria de datos cliente)
siendo:
la velocidad binaria de datos cliente la velocidad binaria tras decodificar el código de línea
en bloque (por ejemplo, 8B/10B), y el número total de bits en el canal los bits de datos
cliente más todos los bits de tara GFP-T
SBW, como función de N, viene dada por:

 bits datos cliente trama GFP − T 

SBW (N ) = (VelocidadMínimadeCanal )  − (Máx. Velocidad datos clientes )
 bits totales trama GFP − T 

SBW ( N ) =
(512)(N )(ChBWmín ) − CSBW
GFPOH + (536)( N )
máx

siendo:
ChBWmín = la anchura de banda del canal de transporte con el extremo más lento de la
tolerancia del reloj de transporte
CSBWmáx = la velocidad de datos de la señal cliente con el extremo más rápido de la
tolerancia del reloj de transporte
GFPOH = el número de bits de tara GFP.
El valor mínimo de N es el valor más pequeño de N tal que SBW(N) > 0:

N mín = 
(CSBWmáx )(GFPOH ) 

 (512 )(ChBWmín ) − (536 )(CSBWmáx ) 
donde la notación x representa el menor entero ≥ x.

Rec. UIT-T G.7041/Y.1303 (08/2005) 53

Los tamaños mínimos de trayecto VC con sus valores de Nmín asociados se muestran en el
cuadro IV.1.

Cuadro IV.1/G.7041/Y.1303 − Capacidad de trayecto SDH y número de superbloques

en cada trama GFP transparente
Velocidad de datos Ejemplo de señal Tamaño de Número mínimo de bloques
cliente no codificada cliente trayecto VC 65B/trama GFP
160 Mbit/s ESCON VC-3-4v 1
216 Mbit/s DVB ASI VC-4-2v 1
425 Mbit/s Canal de fibra VC-4-3v 13
850 Mbit/s Canal de fibra /FICON VC-4-6v 13
1000 Mbit/s Gbit Ethernet VC-4-7v 95
1700 Mbit/s Canal de fibra VC-4-12v 13
3400 Mbit/s Canal de fibra VC-4-24v 13
NOTA – El número mínimo de superbloques que aquí se indica presupone un encabezamiento de
extensión nulo y que no hay FSC opcional de la cabida útil.

IV.3 Cálculo de la anchura de banda disponible para las CMF

La anchura de banda disponible para ser utilizada para tramas de gestión de cliente (CMF) es la
anchura de banda de reserva sujeta a las limitaciones en cuanto al número de CMF que pueden
transmitirse entre dos tramas de datos cliente. Si no existieran restricciones en el número de CMF
que pueden transmitirse, el valor máximo permitido de N daría la máxima anchura de banda
disponible para las CMF, siendo:
Nmáx = (65536-GFPOH)/67
= 978 sin encabezamiento de extensión ni FCS de la cabida útil, y
= 977 con encabezamiento de extensión o FCS de la cabida útil
A fin de minimizar la latencia y los requisitos de la memoria de almacenamiento intermedia
asociados al ingreso al proceso de adaptación de fuente GFP-T, es conveniente no enviar más de
una CMF entre tramas de datos cliente. Cuanto más largas sean las tramas de datos cliente, menos
oportunidades por segundo existirán para transmitir las CMF (es decir, habrá menos intervalos entre
tramas de datos cliente para el envío de las CMF). Como resultado de ello, conforme N aumenta, el
número de oportunidades de transmisión CMF disminuye y, por tanto, disminuye la anchura de
banda disponible para las CMF. Con esta restricción, el valor óptimo de N es el que ocupa toda la
anchura de banda exactamente con una CMF por trama de datos cliente. Un valor menor de N
reduce la anchura de banda de reserva de tal forma que no resulte adecuado permitir que exista una
CMF entre cada trama de datos cliente. Un valor mayor de N daría lugar a un número menor de
CMF por segundo. En general, si se permite la transmisión de m CMF entre tramas de datos cliente,
la anchura de banda para CMF disponible es:
CMFBW ( N , m ) = (CMF segundo )(bits CMF )

CMFBW ( N , m ) =
(ChBWmín )(CMFL )(m )
(m )(CMFL ) + GFPOH + (536)(N )

54 Rec. UIT-T G.7041/Y.1303 (08/2005)

siendo:
CMFL = la longitud de la trama CMF
m = el número de CMF que pueden transmitirse entre tramas de datos cliente, con
la limitación de que:
(512)(N )(ChBWmín ) ≥ CSBWmáx
GFPOH + (536 )( N ) + (m )(CMFL )
La anchura de banda real de la cabida útil de las tramas de gestión de cliente es la relación entre la
cabida útil de la CMF y la longitud total de la trama CMF:
 CMFPAL 
CMPLBW = (CMFBW ( N , M )) 
 CMFL 
siendo:
CMPLBW = la anchura de banda de la cabida útil utilizable para CMF
CMFPAL = el número de bits de la cabida útil CMF utilizados para la cabida útil de CMF
(es decir, la cabida útil menos la pFCS, si ésta se utiliza)
Para un valor dado de m, el valor de N que produce la máxima anchura de banda CMF utilizable es
el entero más próximo a:

N opt =
(CSBWmáx )[GFPOH + (m )(CMFL )]
(512)(ChBWmín ) − (536)(CSBWmáx )

Rec. UIT-T G.7041/Y.1303 (08/2005) 55

 Apéndice V

Requisitos de anchura de banda para el transporte Ethernet

En este apéndice se muestran los requisitos de anchura de banda para el transporte de datos cliente
por Ethernet sobre GFP sobre SONET, en función de la velocidad MAC Ethernet, la longitud del
campo de la cabida útil cliente, de si la red tiene o no un rótulo VLAN insertado, y de si se utiliza o
no el pFCS GFP. Esta información se muestra en los cuadros V.1 a V.4.
NOTA – La velocidad binaria MAC de los cuadros V.1 a V.4 es la velocidad binaria real de las tramas MAC
Ethernet después de la supresión de los intervalos de 12 octetos entre paquetes más el preámbulo de
7 octetos + 1 octeto de inicio del delimitador de trama. En otras palabras, la velocidad binaria
MAC = (velocidad en la interfaz Ethernet) (número de bits de la trama MAC)/(número de bits de la trama
MAC + intervalo de 12 octetos entre paquetes + preámbulo de 7 octetos + inicio de 1 octeto del delimitador
de trama).

Cuadro V.1/G.7041/Y.1303 – Velocidad binaria máxima MAC con (sin) rótulo

por cada señal servidora MAC de "10 Mbit/s"

Velocidad binaria de la cabida útil (velocidad binaria nominal para Ethernet)

10,000 9,600 11,200 8,704 10,880

Velocidad binaria MAC (kbit/s), caudal (%) relativo a la máxima velocidad binaria MAC
Rótulo Tam. MAC
GFP-FCS 10Base-T VC-11-6v Caudal VC-11-7v Caudal VC-12-4v Caudal VC-12-5v Caudal
VLAN (octetos)
0 0 64 7,619 8,533 112.0 9,956 131 7,737 101.5 9,671 127
0 0 128 8,649 9,035 104.5 10,541 122 8,192 94.7 10,240 118
0 0 256 9,275 9,309 100.4 10,861 117 8,440 91.0 10,550 114
0 0 512 9,624 9,452 98.2 11,028 115 8,570 89.0 10,713 111
0 0 1,024 9,808 9,526 97.1 11,113 113 8,637 88.1 10,796 110
0 0 1,518 9,870 9,550 96.8 11,141 113 8,658 87.7 10,823 110
0 0 9,618 9,979 9,592 96.1 11,191 112 8,697 87.1 10,871 109
0 1 64 7,727 8,589 111.2 10,021 130 7,788 100.8 9,735 126
0 1 128 8,684 9,051 104.2 10,560 122 8,207 94.5 10,258 118
0 1 256 9,286 9,313 100.3 10,866 117 8,444 90.9 10,555 114
0 1 512 9,627 9,453 98.2 11,029 115 8,571 89.0 10,714 111
0 1 1,024 9,809 9,526 97.1 11,114 113 8,637 88.0 10,796 110
0 1 1,518 9,870 9,550 96.8 11,141 113 8,658 87.7 10,823 110
0 1 9,618 9,979 9,592 96.1 11,191 112 8,697 87.1 10,871 109
1 0 64 7,619 8,084 106.1 9,432 124 7,330 96.2 9,162 120
1 0 128 8,649 8,777 101.5 10,240 118 7,958 92.0 9,947 115
1 0 256 9,275 9,170 98.9 10,699 115 8,314 89.6 10,393 112
1 0 512 9,624 9,380 97.5 10,944 114 8,505 88.4 10,631 110
1 0 1,024 9,808 9,489 96.7 11,070 113 8,603 87.7 10,754 110
1 0 1,518 9,870 9,525 96.5 11,112 113 8,636 87.5 10,795 109
1 0 9,618 9,979 9,588 96.1 11,186 112 8,693 87.1 10,866 109
1 1 64 7,727 8,160 105.6 9,520 123 7,398 95.7 9,248 120
1 1 128 8,684 8,800 101.3 10,267 118 7,979 91.9 9,973 115
1 1 256 9,286 9,176 98.8 10,706 115 8,320 89.6 10,400 112
1 1 512 9,627 9,382 97.5 10,945 114 8,506 88.4 10,633 110
1 1 1,024 9,809 9,489 96.7 11,071 113 8,604 87.7 10,754 110
1 1 1,518 9,870 9,525 96.5 11,112 113 8,636 87.5 10,795 109
1 1 9,618 9,979 9,588 96.1 11,186 112 8,693 87.1 10,866 109

NOTA 1 − GFP-FCS; No = 0, Sí = 1. Rótulo VLAN; el valor da el número de rótulos VLAN (sin rótulos
VLAN = 0).
NOTA 2 − Tara de encapsulado: 20 octetos para la interfaz Ethernet física (7 octetos de preámbulo, 1 octeto
SFD y un IPG mínimo de 12). Tara de encapsulado de 8 octetos para GFP sin GFP-FCS y tara de
encapsulado de 12 octetos para GFP con GFP-FCS.

56 Rec. UIT-T G.7041/Y.1303 (08/2005)

 Cuadro V.2/G.7041/Y.1303 – Velocidad binaria máxima MAC con (sin) rótulo
por cada señal servidora MAC de "100 Mbit/s"

Velocidad binaria de la cabida útil (velocidad binaria

nominal para Ethernet)
100,000 96,768 149,760

Velocidad binaria MAC (kbit/s), caudal (%) relativo a la

máxima velocidad binaria MAC
GFP- Rótulo Tam. MAC
100Base-T VC-3-2v Caudal VC-4 Caudal
FCS VLAN (octetos)
0 0 64 76,190 86,016 100.0 133,120 100.0
0 0 128 86,486 91,076 100.0 140,951 100.0
0 0 256 92,754 93,836 100.0 145,222 100.0
0 0 512 96,241 95,279 99.0 147,456 100.0
0 0 1,024 98,084 96,018 97.9 148,599 100.0
0 0 1,518 98,700 96,261 97.5 148,975 100.0
0 0 9,618 99,792 96,688 96.9 149,636 100.0
0 1 64 77,273 86,582 100.0 133,996 100.0
0 1 128 86,842 91,238 100.0 141,202 100.0
0 1 256 92,857 93,879 100.0 145,290 100.0
0 1 512 96,269 95,291 99.0 147,474 100.0
0 1 1,024 98,092 96,021 97.9 148,604 100.0
0 1 1,518 98,703 96,262 97.5 148,977 100.0
0 1 9,618 99,793 96,688 96.9 149,636 100.0
1 0 64 76,190 81,489 100.0 126,114 100.0
1 0 128 86,486 88,474 100.0 136,923 100.0
1 0 256 92,754 92,435 99.7 143,054 100.0
1 0 512 96,241 94,552 98.2 146,330 100.0
1 0 1,024 98,084 95,647 97.5 148,025 100.0
1 0 1,518 98,700 96,009 97.3 148,585 100.0
1 0 9,618 99,792 96,647 96.8 149,573 100.0
1 1 64 77,273 82,253 100.0 127,296 100.0
1 1 128 86,842 88,704 100.0 137,280 100.0
1 1 256 92,857 92,499 99.6 143,153 100.0
1 1 512 96,269 94,569 98.2 146,356 100.0
1 1 1,024 98,092 95,651 97.5 148,032 100.0
1 1 1,518 98,703 96,011 97.3 148,588 100.0
1 1 9,618 99,793 96,647 96.8 149,573 100.0

NOTA 1 − GFP-FCS; No = 0, Sí = 1. Rótulo VLAN; el valor da el número de rótulos VLAN (sin rótulos
VLAN = 0).
NOTA 2 − Tara de encapsulado: 20 octetos para la interfaz Ethernet física (7 octetos de preámbulo, 1 octeto
SFD y un IPG mínimo de 12). Tara de encapsulado de 8 octetos para GFP sin GFP-FCS y tara de
encapsulado de 12 octetos para GFP con GFP-FCS.

Rec. UIT-T G.7041/Y.1303 (08/2005) 57

 Cuadro V.3/G.7041/Y.1303 – Velocidad binaria máxima MAC con (sin) rótulo
por cada señal servidora MAC de "1 Gbit/s"

Velocidad binaria de la cabida útil (velocidad binaria nominal

para Ethernet)
1,000,000 898,560 1,048,320

Velocidad binaria MAC (kbit/s), caudal (%) relativo a la máxima

velocidad binaria MAC
GFP- Rótulo Tam. MAC
1000Base-X VC-4-6v Caudal VC-4-7v Caudal
FCS VLAN (octetos)
0 0 64 761,905 798,720 100.0 931,840 100.0
0 0 128 864,865 845,704 97.8 986,654 100.0
0 0 256 927,536 871,331 93.9 1,016,553 100.0
0 0 512 962,406 884,736 91.9 1,032,192 100.0
0 0 1,024 980,843 891,594 90.9 1,040,193 100.0
0 0 1,518 986,996 893,849 90.6 1,042,824 100.0
0 0 9,618 997,925 897,813 90.0 1,047,449 100.0
0 1 64 772,727 803,975 100.0 937,971 100.0
0 1 128 868,421 847,214 97.6 988,416 100.0
0 1 256 928,571 871,737 93.9 1,017,027 100.0
0 1 512 962,687 884,842 91.9 1,032,315 100.0
0 1 1,024 980,916 891,621 90.9 1,040,225 100.0
0 1 1,518 987,030 893,862 90.6 1,042,839 100.0
0 1 9,618 997,926 897,814 90.0 1,047,449 100.0
1 0 64 761,905 756,682 99.3 882,796 100.0
1 0 128 864,865 821,541 95.0 958,464 100.0
1 0 256 927,536 858,326 92.5 1,001,380 100.0
1 0 512 962,406 877,982 91.2 1,024,313 100.0
1 0 1,024 980,843 888,152 90.5 1,036,177 100.0
1 0 1,518 986,996 891,512 90.3 1,040,098 100.0
1 0 9,618 997,925 897,440 89.9 1,047,014 100.0
1 1 64 772,727 763,776 98.8 891,072 100.0
1 1 128 868,421 823,680 94.8 960,960 100.0
1 1 256 928,571 858,918 92.5 1,002,071 100.0
1 1 512 962,687 878,138 91.2 1,024,495 100.0
1 1 1,024 980,916 888,192 90.5 1,036,224 100.0
1 1 1,518 987,030 891,531 90.3 1,040,119 100.0
1 1 9,618 997,926 897,441 89.9 1,047,014 100.0

NOTA 1 − GFP-FCS; No = 0, Sí = 1. Rótulo VLAN; el valor da el número de rótulos VLAN (sin rótulos
VLAN = 0).
NOTA 2 − Tara de encapsulado: 20 octetos para la interfaz Ethernet física (7 octetos de preámbulo, 1 octeto
SFD y un IPG mínimo de 12). Tara de encapsulado de 8 octetos para GFP sin GFP-FCS y tara de
encapsulado de 12 octetos para GFP con GFP-FCS.

58 Rec. UIT-T G.7041/Y.1303 (08/2005)

 Cuadro V.4/G.7041/Y.1303 – Velocidad binaria máxima MAC con (sin) rótulo
por cada señal servidora MAC de "10 Gbit/s"

Velocidad binaria de la cabida útil (velocidad binaria nominal para Ethernet)

10.000.000 9.884.160 9.953.280 9.995.277

Velocidad binaria MAC (kbit/s), caudal (%) relativo a la máxima velocidad binaria MAC
Rótulo Tam. MAC
GFP-FCS 10GBase-R VC-4-66v Caudal ODU1-4v Caudal ODU2 Caudal
VLAN (octetos)
0 0 64 8.311.688 8.785.920 100.0 8.847.360 100.0 8.884.691 100.0
0 0 128 9.078.014 9.302.739 100.0 9.367.793 100.0 9.407.319 100.0
0 0 256 9.516.729 9.584.640 100.0 9.651.665 100.0 9.692.390 100.0
0 0 512 9.752.381 9.732.096 99.8 9.800.153 100.0 9.841.503 100.0
0 0 1.024 9.874.638 9.807.539 99.3 9.876.123 100.0 9.917.794 100.0
0 0 1.518 9.915.088 9.832.343 99.2 9.901.100 99.9 9.942.877 100.0
0 0 9.618 9.986.502 9.875.945 98.9 9.945.008 99.6 9.986.970 100.0
0 1 64 8.395.062 8.843.722 100.0 8.905.566 100.0 8.943.143 100.0
0 1 128 9.103.448 9.319.351 100.0 9.384.521 100.0 9.424.118 100.0
0 1 256 9.523.810 9.589.110 100.0 9.656.167 100.0 9.696.910 100.0
0 1 512 9.754.253 9.733.257 99.8 9.801.322 100.0 9.842.677 100.0
0 1 1.024 9.875.120 9.807.834 99.3 9.876.421 100.0 9.918.093 100.0
0 1 1.518 9.915.309 9.832.478 99.2 9.901.237 99.9 9.943.014 100.0
0 1 9.618 9.986.508 9.875.949 98.9 9.945.011 99.6 9.986.974 100.0
1 0 64 8.311.688 8.323.503 100.0 8.381.709 100.0 8.417.075 100.0
1 0 128 9.078.014 9.036.946 99.5 9.100.142 100.0 9.138.539 100.0
1 0 256 9.516.729 9.441.586 99.2 9.507.611 99.9 9.547.727 100.0
1 0 512 9.752.381 9.657.805 99.0 9.725.342 99.7 9.766.377 100.0
1 0 1.024 9.874.638 9.769.672 98.9 9.837.991 99.6 9.879.502 100.0
1 0 1.518 9.915.088 9.806.637 98.9 9.875.215 99.6 9.916.883 100.0
1 0 9.618 9.986.502 9.871.843 98.9 9.940.877 99.5 9.982.822 100.0
1 1 64 8.395.062 8.401.536 100.0 8.460.288 100.0 8.495.985 100.0
1 1 128 9.103.448 9.060.480 99.5 9.123.840 100.0 9.162.337 100.0
1 1 256 9.523.810 9.448.094 99.2 9.514.165 99.9 9.554.309 100.0
1 1 512 9.754.253 9.659.520 99.0 9.727.069 99.7 9.768.112 100.0
1 1 1.024 9.875.120 9.770.112 98.9 9.838.434 99.6 9.879.947 100.0
1 1 1.518 9.915.309 9.806.839 98.9 9.875.419 99.6 9.917.087 100.0
1 1 9.618 9.986.508 9.871.848 98.9 9.940.882 99.5 9.982.827 100.0

NOTA 1 − GFP-FCS; No = 0, Sí = 1. Rótulo VLAN; el valor da el número de rótulos VLAN (sin rótulos
VLAN = 0).
NOTA 2 − Tara de encapsulado: 13 octetos para la interfaz Ethernet física (7 octetos de preámbulo, 1 octeto
SFD y un IPG mínimo de 5). Tara de encapsulado de 8 octetos para GFP sin GFP-FCS y tara de encapsulado
de 12 octetos para GFP con GFP-FCS.

Rec. UIT-T G.7041/Y.1303 (08/2005) 59

 RECOMENDACIONES UIT-T DE LA SERIE Y
INFRAESTRUCTURA MUNDIAL DE LA INFORMACIÓN, ASPECTOS DEL PROTOCOLO INTERNET Y
REDES DE LA PRÓXIMA GENERACIÓN

INFRAESTRUCTURA MUNDIAL DE LA INFORMACIÓN

Generalidades Y.100–Y.199
Servicios, aplicaciones y programas intermedios Y.200–Y.299
Aspectos de red Y.300–Y.399
Interfaces y protocolos Y.400–Y.499
Numeración, direccionamiento y denominación Y.500–Y.599
Operaciones, administración y mantenimiento Y.600–Y.699
Seguridad Y.700–Y.799
Características Y.800–Y.899
ASPECTOS DEL PROTOCOLO INTERNET
Generalidades Y.1000–Y.1099
Servicios y aplicaciones Y.1100–Y.1199
Arquitectura, acceso, capacidades de red y gestión de recursos Y.1200–Y.1299
Transporte Y.1300–Y.1399
Interfuncionamiento Y.1400–Y.1499
Calidad de servicio y características de red Y.1500–Y.1599
Señalización Y.1600–Y.1699
Operaciones, administración y mantenimiento Y.1700–Y.1799
Tasación Y.1800–Y.1899
REDES DE LA PRÓXIMA GENERACIÓN
Marcos y modelos arquitecturales funcionales Y.2000–Y.2099
Calidad de servicio y calidad de funcionamiento Y.2100–Y.2199
Aspectos relativos a los servicios: capacidades y arquitectura de servicios Y.2200–Y.2249
Aspectos relativos a los servicios: interoperabilidad de servicios y redes en las redes de próxima Y.2250–Y.2299
generación
Numeración, denominación y direccionamiento Y.2300–Y.2399
Gestión de red Y.2400–Y.2499
Arquitecturas y protocolos de control de red Y.2500–Y.2599
Seguridad Y.2700–Y.2799
Movilidad generalizada Y.2800–Y.2899

Para más información, véase la Lista de Recomendaciones del UIT-T.

 SERIES DE RECOMENDACIONES DEL UIT-T

Serie A Organización del trabajo del UIT-T

Serie D Principios generales de tarificación

Serie E Explotación general de la red, servicio telefónico, explotación del servicio y factores humanos

Serie F Servicios de telecomunicación no telefónicos

Serie G Sistemas y medios de transmisión, sistemas y redes digitales

Serie H Sistemas audiovisuales y multimedios

Serie I Red digital de servicios integrados

Serie J Redes de cable y transmisión de programas radiofónicos y televisivos, y de otras señales

multimedios

Serie K Protección contra las interferencias

Serie L Construcción, instalación y protección de los cables y otros elementos de planta exterior

Serie M Gestión de las telecomunicaciones, incluida la RGT y el mantenimiento de redes

Serie N Mantenimiento: circuitos internacionales para transmisiones radiofónicas y de televisión

Serie O Especificaciones de los aparatos de medida

Serie P Calidad de transmisión telefónica, instalaciones telefónicas y redes locales

Serie Q Conmutación y señalización

Serie R Transmisión telegráfica

Serie S Equipos terminales para servicios de telegrafía

Serie T Terminales para servicios de telemática

Serie U Conmutación telegráfica

Serie V Comunicación de datos por la red telefónica

Serie X Redes de datos, comunicaciones de sistemas abiertos y seguridad

Serie Y Infraestructura mundial de la información, aspectos del protocolo Internet y Redes de la

próxima generación

Serie Z Lenguajes y aspectos generales de soporte lógico para sistemas de telecomunicación

Impreso en Suiza
Ginebra, 2006