ES2316869T3 - Filtrado de paquetes de datos en una pasarela de red que funciona como punto de aplicacion politica local basada en el servicio (sblp). - Google Patents
Filtrado de paquetes de datos en una pasarela de red que funciona como punto de aplicacion politica local basada en el servicio (sblp). Download PDFInfo
- Publication number
- ES2316869T3 ES2316869T3 ES03811018T ES03811018T ES2316869T3 ES 2316869 T3 ES2316869 T3 ES 2316869T3 ES 03811018 T ES03811018 T ES 03811018T ES 03811018 T ES03811018 T ES 03811018T ES 2316869 T3 ES2316869 T3 ES 2316869T3
- Authority
- ES
- Spain
- Prior art keywords
- address
- network
- destination
- node
- packets
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0263—Rule management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
- H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/16—Gateway arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un método de filtrado de paquetes de datos en una pasarela de red, donde los paquetes de datos son transmitidos desde un nodo de origen a un nodo de destino a través de la mencionada pasarela de red, durante una sesión de comunicación de datos de paquetes, y tienen una cabecera que incluye una dirección de destino y una cabecera de extensión, y donde el nodo de destino y el nodo de origen tienen una primera dirección de red durante un primer período de la sesión de comunicación de datos de paquetes, y una segunda dirección de red diferente, durante un segundo período subsiguiente de la sesión de comunicación de datos, el método comprendiendo: utilizar la cabecera de extensión para la transmisión de informaciones de dirección durante el segundo período; y bloquear selectivamente aquellos paquetes de datos en los que ni la dirección de destino ni la cabecera de extensión, se ajusten a un criterio de dirección predeterminado.
Description
Filtrado de paquetes de datos en una pasarela de
red que funciona como punto de aplicación Política Local Basada en
el Servicio (SBLP).
La presente invención se refiere a aparatos y
métodos para habilitar un nodo de pasarela de una red de datos por
conmutación de paquetes, para mantener un filtro de paquetes basado
en la dirección de destino, cuando la dirección de destino de la
cabecera del paquete cambia durante una sesión.
Más en concreto pero no exclusivamente, la
presente invención se refiere a aparatos y métodos para habilitar
un nodo de soporte de pasarela del servicio general de
radiocomunicaciones por paquetes (GGSN, General Packet Radio
Service Gateway Support Node) de una red del servicio general de
radiocomunicaciones por paquetes (GPRS, General Packet Radio
Service) 2G o 3G, para aplicar funciones de control basadas de
Política Local Basada en el Servicio (SBLP,
Service-Based Local Policy), en base a la dirección
de destino de paquetes que salen de la red GPRS o llegan a esta,
soportando a la vez itinerancia de red que puede tener como
resultado un cambio en la dirección de destino durante una sesión
IP.
Si bien las redes móviles 2G convencionales,
tales como las que constituyen los estándares del sistema global
para comunicaciones móviles (GSM, Global System for Mobile
Communications) han proporcionado a las estaciones móviles (MSs,
mobile stations) de los usuarios, servicios de datos y voz con
conmutación de circuitos, hay una gran ocasión en la industria de
las telecomunicaciones móviles para desplegar redes móviles por
conmutación de paquetes. Las redes móviles por conmutación de
paquetes tienen ventajas significativas en términos de eficiencia
en los recursos de red de radio, y también permiten la provisión de
servicios de usuario más avanzados. Con la convergencia de las
redes de telecomunicaciones fijas y móviles, el protocolo de
Internet (IP, Internet Protocol), generalizado en redes fijas, es
la elección natural como mecanismo de encaminamiento de paquetes
para las redes de paquetes móviles. Actualmente, la versión 4 de IP
(IPv4) se utiliza ampliamente en el dominio de redes fijas. No
obstante, se espera que evolucione gradualmente a la versión 6 de IP
(IPv6), que ofrece beneficios evidentes sobre IPv4, especialmente
en términos de espacio de direcciones sensiblemente incrementado,
encaminamiento más eficiente, mayor escalabilidad, seguridad
mejorada, integración de la calidad de servicio (QoS, Quality of
Service), soporte para multidifusión y otras características.
Ejemplos concretos de servicios por conmutación
de paquetes que están desplegándose actualmente, incluyen el
servicio general de radiocomunicaciones por paquetes (GPRS) en su
implementación tanto en redes GSM 2G como en redes del sistema
universal de telecomunicaciones móviles (UMTS, Universal Mobile
Telecommunications System) 3G (en lo que sigue, aludidas como redes
GPRS). También está previsto que tecnologías de acceso inalámbrico
diferente de GPRS, tales como la red de área local inalámbrica
(wLAN, wireless Local Area Network), proporcionen un complemento
flexible y económico al GPRS, para el acceso al servicio de banda
ancha local en algunas áreas tales como áreas de acceso inalámbrico
público (centros de conferencias, aeropuertos, centros de
exhibiciones, etc.). Por consiguiente, los operadores de redes
móviles desearan soportar la itinerancia de estaciones móviles
entre redes o subredes, GPRS y no GPRS.
Se remite al lector a la especificación técnica
GPRS Service Description (versión 1999), aludida como 3G TS 23.060
v3.12.0 (2002-06) y disponible en la página web de
3GPP en la dirección
http://www.3pp.org/ftp/specs/2002-06/R1999/23_series/,
que proporciona una descripción detallada del servicio, para redes
de paquetes móviles 2G (GPRS/GSM) y 3G (GPRS UMTS). La
funcionalidad de las redes GPRS es también conocida de forma
generalizada, si bien más abajo se describirá en detalle aspectos
adicionales.
Para acceder a servicios por conmutación de
paquetes GPRS, una MS lleva a cabo primero un procedimiento de
conexión GPRS con una SGSN (sea una conexión GPRS GSM 2G, o bien una
conexión GPRS UMTS 3G). Se lleva a cabo procedimientos de
autenticación y actualización de localización y, si son
satisfactorios, el procedimiento de conexión GPRS hace a la MS
disponible para paginación a través de la SGSN, y para notificación
de datos de paquete entrantes. Sin embargo, de hecho para enviar y
recibir datos de paquetes la MS debe tener una dirección de
protocolo de datos de paquetes (PDP, Packet Data Protocol) asignada
(por ejemplo una dirección IP) y debe activar al menos un contexto
PDP para ser utilizado con tal dirección PDP. Cada dirección PDP
para una MS puede tener uno o más contextos PDP asociados con esta,
y los datos que definen los contextos PDP se memorizan en la MS, la
SGSN y la GGSN. El proceso de activación de contexto PDP hace que la
MS sea conocida no solo para la SGSN sino también para la
correspondiente GGSN, y que pueda dar comienzo el entrelazado con
redes de datos externos.
Si bien las redes GPRS, al haber sido diseñadas
desde principio como redes móviles, tienen incorporada
administración de movilidad (para MSs dentro de la red GPRS) y
funcionalidad de itinerancia (para MSs itinerantes entre redes
GPRS), también se ha llevado a cabo un trabajo en el Grupo de
Trabajo sobre Ingeniería de Internet (IETF, Internet Engineering
Task Force) para soportar movilidad de terminales de usuario IP en
general. A este respecto, el IETF ha desarrollado los protocolos de
IP móvil (MIP, Mobile IP). MIP está diseñado para soportar movilidad
cuando las estaciones móviles (o los nodos móviles (MNs) en
terminología MIP) se mueven entre redes IP con diferentes prefijos
de subred (macro-movilidad). Por ejemplo, MIP puede
utilizarse para soportar movilidad entre una red GPRS y una red no
GPRS tal como una red wLAN. No se prevé el uso de IP móvil para
administración de movilidad dentro de una red una subred
(micro-movilidad), que típicamente se administra
mediante mecanismos de capa específica de tecnología de acceso 2,
tales como traspaso suave WCDMA.
Hay dos versiones de MIP correspondientes a las
dos versiones de IP. La versión 4 de MIP (MIPv4) está diseñada para
proporcionar movilidad de dirección IP para direcciones de la
versión 4 de IP (IPv4), mientras que la más nueva versión 6 de MIP
(MIPv6) está diseñada para proporcionar movilidad de dirección IP
para direcciones de IP versión 6 (IPv6). MIPv4 se describe en la
petición de comentario (RFC, Request For Comment) IETF de 2002,
disponible en la página web del IETF en la dirección
http://www.ietf.orglrfclrfc2002.txt?number=2002. MIPv6 se
describe en el borrador de IETF en Internet "Mobility Support in
IPv6", en el momento de escribir este documento disponible en la
página web del IETF en la dirección
http://www.ietf.org/intenzet-draftsldraft-ietf-mobileip-ipv6-19.txt
y aludida como
draft-ietf-mobileip-ipv6-l9.txt,
con fecha de 29 de octubre de 2002.
En la figura 1 se ilustra un escenario que
involucra itineración MIP con optimización de encaminamiento. Se
asigna una dirección de IP local (HAddr, home IP address) a un MN,
en su red local (HN, Home Network). Los procedimientos de
encaminamiento en la HN en aseguran que, siempre que el MN esté
dentro de la HN, un paquete IP enviado desde un nodo
correspondiente (CN, Correspondent Node) sobre una red IP, alcanzará
el MN. Cuando el MN pasa a una red ajena (FN, foreign network), el
MN recibe la asignación de una dirección provisional (CoA,
Care-of Address) dentro de la FN, a la que habrá de
encaminarse los paquetes IP. Sin embargo, el movimiento del MN debe
ser transparente para la capa IP y las capas superiores (por
ejemplo, la capa de transporte y la etapa de aplicación) durante
una sesión, de forma que los paquetes creados por la capa IP sobre
el CN continúen llevando la HAddr como dirección de destino.
Bajo el protocolo de optimización de
encaminamiento MIPv6, el MN envía una actualización de conexión al
CN cuando pasa a la FN, para informar al CN del CoA. La capa MIP
del CN establece entonces la dirección de destino de los paquetes
subsiguientes en la sesión, al CoA, y coloca la HAddr del MN en una
de Cabecera de Encaminamiento Tipo 2, como la cabecera de extensión
del paquete. En la capa MIP MN, se recibe la HAddr desde el campo de
Cabecera de Encaminamiento Tipo 2, y es utilizada como la dirección
de destino en el correspondiente paquete pasado a la capa IP del
MN.
En este escenario, el CN está localizado en una
red GPRS (GN) interconectada a la red IP a través de un nodo de
soporte de pasarela del servicio general de radiocomunicaciones por
paquetes (GGSN, General Packet Radio Service Gateway Support Node),
con funciones tales como las definidas en el documento 3GPP TS
23.207 V5.3.0 (marzo de 2002), cláusula 5.2.1. El GGSN incluye un
punto de aplicación de política local basada en servicio (SBLP,
Service-Based Local Policy), que aplica control de
admisión basado en políticas, a los paquetes que pasan a través de
la GGSN. La aplicación de políticas para una sesión individual está
definida mediante una 'puerta', definiéndose independientemente
puertas para tráfico ascendente y descendente. Cada puerta incluye
un clasificador de paquetes, y acciones a adoptar para paquetes que
se ajustan al clasificador de paquetes. El clasificador de paquetes
incluye dirección IP de origen, dirección IP de destino, puerto de
origen, puerto de destino y protocolo. Las direcciones de origen y
destino IP del clasificador de paquetes pueden incluir comodines
para definir un rango de direcciones. Los paquetes que no se ajustan
al clasificador de paquetes de la correspondiente puerta son
bloqueados.
Para establecer una sesión IP a través de la
GGSN, el CN envía a la GGSN una solicitud de autorización
especificando la dirección IP de origen, la dirección IP de destino
(es decir, la HAddr), el puerto de origen, el puerto de destino y
el protocolo. Un punto de decisión de SBLP dentro de la GGSN (el
punto de decisión local), tal como se define en la cláusula 5.2.3
del documento 3GPP TS 23.207 V5.3.0 (marzo de 2002), o una función
de control de políticas (PCF, Policy Control Function) fuera del
GGSN, determinan si se autoriza la sesión IP. Si se autoriza la
sesión se establece una puerta para cada dirección de la sesión,
como el punto de aplicación de SBLP, y se transmite un vale de
autorización al CN. El vale de autorización es conforme a la
especificación IETF sobre extensiones SIP para autorizaciones de
medios.
Puede utilizarse una SBLP de enlace ascendente
para impedir el acceso mediante el CN (u otros nodos dentro de la
GN) a direcciones IP de destino especificadas. Así, una puerta puede
ser autorizada solo si la dirección IP de destino solicitada es
aceptable bajo la SBLP. Sin embargo, una puerta semejante
interferirá con el protocolo de optimización de encaminamiento
MIPv6 descrito arriba, debido a que la dirección de destino que ve
el GGSN cambia de la HAddr a la CoA en la sesión intermedia. Los
paquetes dirigidos a la CoA no se ajustan al clasificador de
paquetes en la puerta de enlace ascendente correspondiente a la
sesión, y pueden ser bloqueados.
La optimización de encaminamiento es obligatoria
en MIPv6, pero opcional en MIPv4. Una ruta alternativa sin
optimización de ruta se muestra en la figura 2. Se establece una
sesión IP entre el CN y el MN en su HN. El MN pasa a la FN durante
la sesión, y envía una actualización de conexión para informar a un
agente local (HA, Home Agent) en la HN, de la CoA en la FN. En este
ejemplo la FN es una red GPRS conectada al IPN a través de un
GGSN.
En respuesta a la actualización de conexión, el
HA establece un túnel IP para la CoA mediante interceptar
cualesquiera paquetes subsiguientes con la HAddr como dirección de
destino, y encapsularlos en paquetes con la dirección IP del HA
establecido, la dirección de origen, y la CoA del MN establecida
como dirección de destino. La capa de MIP del MN desencapsula los
paquetes y los pasa a la capa IP, de forma que la itineración es
transparente a la capa IP y a las capas superiores. Esta
tunelización puede conseguirse utilizando el mecanismo de
tunelización de paquete genérico IPv6, descrita en el documento IETF
RFC 2473.
En la dirección de enlace ascendente, el MN
puede no necesitar cambiar las direcciones de origen y destino de
sus paquetes tras pasar a la FN, debido a que la dirección IP del CN
no haya cambiado. Sin embargo, el GGSN puede aplicar un filtro de
salida para los paquetes salientes, de forma que cualesquiera
paquetes con una dirección de origen que no esté dentro de la FN
son bloqueados. Esto puede implementarse mediante una puerta SBLP
con una dirección de origen del clasificador de paquetes, definida
para ajustarse a cualquier dirección IP dentro del GGSN. Como
resultado, se bloquearía paquetes procedentes del MN que lleven la
HAddr como dirección de
origen.
origen.
Para tratar este problema, los estándares MIPv4
y MIPv6 incluyen un protocolo de tunelización inversa en el que el
MN establece un túnel en la dirección de enlace ascendente, entre su
CoA y la dirección HA. Puesto que los paquetes de enlace ascendente
son encapsulados en paquetes que lleva la CoA como dirección de
origen, y la CoA está dentro de la FN, el filtro de salida
permitirá pasar a los paquetes encapsulados. El HA desencapsula los
paquetes y los transfiere al CN. La tunelización inversa MIPv6 se
describe por ejemplo en el borrador del grupo de trabajo de IP
móvil del IETF, 'Mobility Support in IPv6', de 29 de octubre de
2002, y que al escribir este documento se encuentra en la dirección
web
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txt.
Sin embargo, esta solución de lugar a un
problema cuando el GGSN en la FN ha implementado una puerta SBLP
para los paquetes de enlace ascendente. Cuando el MN entra en la FN
debe enviar una solicitud de autorización al GGSN, para permitir
que la sesión IP con el CN sea encaminada a través del GGSN. Esta no
sería un problema en sí mismo, puesto que el protocolo de
autorización permite la autorización en la sesión intermedia,
incluso cuando la sesión ha comenzado fuera de la red local GGSN.
Sin embargo, la solicitud de autorización originada en la capa de
aplicación (por ejemplo, capa de sesión SIP) especificará la
dirección de HA como la dirección de destino, y la dirección de HA
no identifica la dirección de destino final debido a que la
administración de movilidad del MN (por ejemplo, el uso de CoA) es
transparente a la capa de aplicación. Autorizar una puerta SBLP de
enlace ascendente en función de la dirección de HA frustraría el
objetivo de la puerta SBLP, y entonces el punto de aplicación de
SBLP no tendría control sobre el destino final de los paquetes
salientes. Además, no se permite al GGSN examinar la carga útil de
los paquetes encapsulados para descubrir la dirección final de
destino, y ni siquiera puede ser capaz de hacerlo si la carga útil
está cifrada, por ejemplo utilizando IPSec.
Una realización proporciona un método de
filtrado de paquetes de datos en una pasarela de red, los paquetes
de datos teniendo una cabecera que incluye una dirección de destino
y una cabecera de extensión, el método comprendiendo bloquear
selectivamente aquellos paquetes de datos en los que ni la dirección
de destino ni la cabecera de extensión se ajusten a un criterio de
dirección predeterminado.
De acuerdo con un aspecto de la presente
invención, se proporciona un método como el enunciado en la
reivindicación 1. De acuerdo con otro aspecto, se proporciona un
método como el reivindicado en la reivindicación 13.
El documento US 2002/0 036 983 discute un método
de filtrado y control de flujo de datos en una conexión QoS entre
la central remota y un equipo de usuario, en una red de datos de
paquetes que utiliza mecanismos de control de políticas, incluyendo
una central que inicia una aplicación en un servidor de aplicación y
una correspondiente sesión entre la central remota y el equipo de
usuario a través del servidor de aplicación. El documento US 2002/0
126 642 discute un sistema de comunicación para un nodo móvil acorde
con IPv6, en el que se configura un prefijo de red virtual como
prefijo específico para un nodo móvil en un dominio que tiene una
pluralidad de subredes, donde en el dominio pueden coexistir nodos
que pueden identificar un prefijo de red virtual, y nodos que no
pueden.
Se describirá realizaciones específicas de la
presente invención, con referencia a los dibujos anexos, en los
cuales:
la figura 1 es un diagrama que ilustra un
problema que surge al intentar aplicar una SBLP saliente en un GGSN
donde el nodo de destino está itinerando utilizando optimización de
ruta;
la figura 2 es un diagrama conceptual que
ilustra un problema que surge al intentar aplicar una SBLP saliente
a un túnel inverso;
la figura 3a es un diagrama de señal que ilustra
optimización de ruta en el escenario de la figura 1;
la figura 3b es un diagrama de flujo del
funcionamiento de un punto de aplicación de SBLP, que aplica una
puerta SBLP saliente en una primera realización de la presente
invención;
la figura 4a es un diagrama de señal que ilustra
una segunda realización de la invención, para solucionar el
problema ilustrado en la figura 1;
la figura 4b es un diagrama de flujo del
funcionamiento de un punto de aplicación de SBLP, que aplica una
puerta SBLP saliente en la segunda realización;
la figura 5a es un diagrama de señal de una
tercera realización de la invención, para solucionar el problema
ilustrado en la figura 2;
la figura 5b es un diagrama de flujo del
funcionamiento de un punto de aplicación de SBLP, que aplica una
puerta SBLP saliente en la tercera realización; y
la figura 6 es un diagrama de flujo del
funcionamiento de un punto de aplicación de SBLP, que aplica una
puerta SBLP saliente en una cuarta realización de la presente
invención.
Una primera realización de la invención
proporciona una primera solución al problema de aplicar funciones
de control basadas en SBLP, donde se utiliza optimización de ruta
MIPv6 en itineración de subred, como se ha descrito arriba con
referencia a la figura 1. En optimización de ruta MIPv6, la HAddr se
memoriza en la cabecera de extensión de Cabecera de Encaminamiento
Tipo 2 (T2H), de forma que pueda ser recibida por la capa MIP del
MN y restablecida como la dirección de destino en paquetes que pasan
a la capa IP.
Como se muestra en la figura 3a, los paquetes
enviados desde el CN al MN durante una sesión IP antes de que el MN
pase a la FN, tienen la HAddr como su dirección IP de destino (DA).
Cuando el MN pasa a la FN, envía al CN una actualización de
conexión (BU, binding update) que incluye la CoA. De acuerdo con el
protocolo de optimización de encaminamiento MIPv6, en respuesta a
la BU el CN envía sus siguientes paquetes dirigidos a la CoA, con
la HAddr en la T2H.
El presente inventor ha considerado que la
cabecera de extensión de Cabecera de Encaminamiento Tipo 2 podría
ser inspeccionada por el GGSN para identificar la dirección de
destino final del paquete. El clasificador de paquetes convencional
no incluye una dirección IP de cabecera de extensión de Cabecera de
Encaminamiento Tipo 2. Sin embargo, los protocolos SBLP son locales
a su propia red, de forma que la aplicación de SBLP puede ser
modificada sin dar lugar a problemas de interoperabilidad con otras
redes.
En la primera realización, como se muestra en la
figura 3B, se crea un clasificador de paquetes convencional para
una puerta SBLP saliente, que incluye una dirección de destino del
clasificador de paquetes PCD. El punto de aplicación de SBLP
implementa la puerta por medio de comparar la dirección de destino
del clasificador de paquetes PCD con la dirección de destino PD
(etapa 30) y la cabecera de extensión de Cabecera de Encaminamiento
Tipo 2 (etapa 32). Si ninguna coincide el paquete es bloqueado
(etapa 34), y en cualquier otro caso se permite pasar el paquete
(etapa 36), sujeto a cualesquiera otras condiciones de control.
La solución de la primera realización es
ventajosa debido a que necesita la modificación solo del punto de
aplicación de SBLP, y no del comportamiento del MN en el CN, ni la
creación de cualesquiera nuevos objetos tales como agentes remotos.
Podría conseguirse un efecto similar mediante definir un
clasificador de paquetes extendido, que especifique una cabecera de
extensión de Cabecera de Encaminamiento Tipo 2 a ser cotejada, como
alternativa a la dirección IP de destino, pero la cabecera de
extensión de Cabecera de Encaminamiento Tipo 2 es redundante pues
se espera sea la misma que la HAddr en el clasificador de paquetes.
El efecto podría conseguirse mediante distribuir la funcionalidad
de forma diferente entre los objetos internos al GGSN.
Aunque la solución de inspeccionar la cabecera
de extensión de Cabecera de Encaminamiento Tipo 2 no está prohibida
mediante MIPv6, se puede considerar que viola el objetivo previsto
de la cabecera de extensión de Cabecera de Encaminamiento Tipo 2,
que es restablecer la dirección de destino original localmente en el
equipo del usuario de destino. Si se implementará medidas técnicas
para impedir tal violación, frustrarían la solución de la primera
realización.
En una segunda realización que se ilustra en la
figura 4a, la dirección de destino final (HAddr) está almacenada en
una cabecera de extensión de opciones
salto-a-salto HH de paquetes
salientes. Tanto IPv4 como IPv6 permiten una cabecera de
extensiones de opciones
salto-a-salto, que debe ser leída
por los nodos intermedios. La existencia de la cabecera de
extensión de opciones salto-a-salto
IPv6 se indica mediante colocar un cero en el campo Siguiente
Cabecera IPv6.
En respuesta a la BU enviada por el MN al CN, el
CN memoriza la HAddr en la HH de los paquetes subsiguientes. Esta
acción se lleva a cabo además del almacenamiento de la HAddr en la
cabecera tipo 2 y la CoA en el campo de dirección IP de
destino.
Como se muestra en la figura 4b, el punto de
aplicación de SBLP compara la dirección de destino del clasificador
de paquetes PCD con la dirección de destino del paquete PD (etapa
40), y también con cualesquiera direcciones IP en la HH (etapa 42).
Si ninguna coincide el paquete es bloqueado (etapa 44). En cualquier
otro caso se permite el paso del paquete (etapa 46), sujeto a
cualesquiera otras restricciones.
La segunda realización es preferible a la
primera realización, por cuanto que el GGSN solo inspecciona campos
que le está permitido inspeccionar, y por lo tanto se puede confiar
en que no se introducirá medidas técnicas que frustren la solución
de la segunda realización. Sin embargo, la segunda realización
necesita un cambio en el comportamiento del MN que sea compatible
con las especificaciones del borrador de Internet MIPv6 existente,
mientras que no es el caso en la primera realización.
Una tercera realización proporciona una primera
solución al problema de aplicar una puerta saliente SBLP sobre un
túnel inverso, como se ha descrito arriba con referencia a la figura
2. El túnel inverso oculta la dirección CN en la carga útil, que
puede ser cifrada. Así, la tercera realización utiliza una solución
similar a la de la segunda realización.
Como se muestra en la figura 5a, en una sesión
IP el MN envía inicialmente paquetes al CN con la dirección de
origen de paquetes PS ajustada a la HAddr, y la PD ajustada a la
dirección CN (CNAddr). Cuando el MN pasa a la FN, envía una BU a su
HA y después establece un túnel IP inverso entre su CoA y el AHA en
la dirección HA (HAAddr).
En esta realización, el MN incluye la CNAddr (o
la dirección local del CN, en el caso de que la propia CN sea móvil
y esté lejos de su red local utilizando IPv6 móvil para movilidad)
en la HH de los paquetes de tunelización inversa. Como se muestra
en la figura 5b, el punto de aplicación de SBLP compara la dirección
de destino del clasificador de paquetes PCD con la dirección IP de
destino de paquetes PD (etapa 50), y también con cualesquiera
direcciones IP en la HH (etapa 52). Si no hay ninguna coincidencia
el paquete es bloqueado (etapa 54). En cualquier otro caso se
permite pasar al paquete (etapa 56), sujeto a cualesquiera otras
restricciones.
La tercera realización requiere funcionalidad
adicional en el CN, respecto de la que ya se requería para
tunelización inversa. En un ejemplo que no cae dentro del alcance
de las reivindicaciones, se proporciona una solución al problema de
aplicación de una puerta saliente SBLP sobre un túnel inverso, que
no necesita tal funcionalidad adicional.
En este ejemplo se define un clasificador de
paquetes extendido PCHA que incluye una dirección IP de HA. Como se
muestra en la figura 6, el punto de aplicación de SBLP compara la
dirección de destino de paquetes PD con la dirección de destino del
clasificador de paquetes PCD (etapa 60) y con la dirección HA del
clasificador de paquetes PCHA (etapa 62). Si no hay ninguna
coincidencia el paquete es bloqueado (etapa 64). En cualquier otro
caso se permite pasar al paquete (etapa 66), sujeto a cualesquiera
otras restricciones.
Como se ha explicado arriba, esto puede tener
como resultado el efecto de que se niegue la SBLP, salvo que exista
una relación de confianza o de control entre el GGSN y el HA.
Como un ejemplo de una relación de control, el
GGSN de la FN y el HA de la HN pueden tener acceso a un punto de
decisión de SBLP común, que emite autorizaciones para puntos de
aplicación de SBLP en la FN y la HN, en función de una política
común. Alternativamente, para reducir el tráfico de autorización
entre la FN y la HN, el punto de decisión de SBLP puede ser
replicado entre la FN y la HN, por ejemplo mediante compartir listas
de direcciones IP bloqueadas.
Como ejemplo de una relación de confianza, el
punto de decisión de SBLP del GGSN puede almacenar una lista de
direcciones IP de HA de confianza, y autorizar puertas con
clasificadores de paquetes que contienen una dirección de HA
presente en la lista. El GGSN no tiene ningún control sobre la SBLP
del HA, pero confía en este para mantener una SBLP conforme con su
propia SBLP. La relación de confianza puede revocarse mediante
retirar la dirección HA de la lista de direcciones de confianza.
Si bien las realizaciones anteriores han sido
descritas con referencia a una SBLP en una red GPRS, se comprenderá
que en otros contextos puede necesitarse un filtro de paquetes
basado en la dirección de destino, tales como cortafuegos en redes
IP locales, que necesitan no ser redes inalámbricas. En el escenario
de la figura 1, el CN podría ser un nodo dentro de la red IP local.
El cambio aparente en la dirección de destino podría surgir en
otros contextos diferentes a la optimización de ruta MIPv6. Por
ejemplo, las disposiciones de transferencia de IP pueden requerir
que la dirección de destino establecida por el nodo de transmisión
sea modificada en sesión intermedia, al objeto de transferir la
sesión a otro dispositivo físico. Variantes de las realizaciones
primera y segunda pueden ser aplicables a estos contextos
alternativos.
Análogamente, una disposición de tunelización
inversa puede surgir en contextos diferentes a la itineración en IP
móvil, y en estos contextos alternativos serían aplicables variantes
de las realizaciones tercera y cuarta.
Si bien las realizaciones describen un filtro
basado en destino, aplicado en paquetes salientes en una pasarela
de una red que es local para el nodo de transmisión, el filtro
basado en destino podría ser aplicado a paquetes entrantes en una
pasarela de una red remota al nodo de transmisión. En las
realizaciones segunda y tercera, esto requeriría estandarización
entre las redes remota y local, para asegurar que la dirección de
destino es situada en la HH mediante el nodo de transmisión.
En las realizaciones primera a tercera, no es
esencial que el punto de aplicación de SBLP verifique en todo
momento tanto la dirección de destino del paquete como la cabecera
de extensión; en su lugar, la puerta puede inicialmente verificar
solo la dirección de destino del paquete, y la puerta puede ser
modificada en respuesta al evento de itineración al objeto de
verificar solo la cabecera de extensión.
Las realizaciones anteriores se proporcionan
solo a modo de ejemplo, y modificaciones o variantes de estas
pueden caer también dentro del alcance de la invención.
\vskip1.000000\baselineskip
La lista de referencias citadas por el
solicitante es solo para comodidad del lector. No forma parte del
documento de Patente Europea. Aunque se ha tomado especial cuidado
en recopilar las referencias, no puede descartarse errores u
omisiones y la EPO rechaza toda responsabilidad a este
respecto.
\bullet US 2002 0 036 983 A [0021]
\bullet US 2002 0 126 642 A [0021]
Claims (15)
1. Un método de filtrado de paquetes de datos en
una pasarela de red, donde los paquetes de datos son transmitidos
desde un nodo de origen a un nodo de destino a través de la
mencionada pasarela de red, durante una sesión de comunicación de
datos de paquetes, y tienen una cabecera que incluye una dirección
de destino y una cabecera de extensión, y donde el nodo de destino
y el nodo de origen tienen una primera dirección de red durante un
primer período de la sesión de comunicación de datos de paquetes, y
una segunda dirección de red diferente, durante un segundo período
subsiguiente de la sesión de comunicación de datos, el método
comprendiendo:
- utilizar la cabecera de extensión para la transmisión de informaciones de dirección durante el segundo período; y
- bloquear selectivamente aquellos paquetes de datos en los que ni la dirección de destino ni la cabecera de extensión, se ajusten a un criterio de dirección predeterminado.
\vskip1.000000\baselineskip
2. El método de la reivindicación 1, en el que
el criterio de dirección se aplica solo a paquetes transmitidos
desde un nodo de origen a un nodo de destino, durante una
correspondiente sesión de comunicación de datos de
paquetes.
paquetes.
3. El método de la reivindicación 2, en el que
el nodo de origen transmite paquetes que tienen la primera dirección
de red como dirección de destino durante el primer período, y
transmite paquetes que tienen la segunda dirección de red como
dirección de destino y la primera dirección de red en la cabecera de
extensión, durante el segundo
período.
período.
4. El método de la reivindicación 3, en el que
el nodo de destino convierte paquetes recibidos durante el segundo
período, mediante reemplazar la segunda dirección de red con la
primera dirección de red, antes de descodificar la carga útil de
los paquetes.
5. El método de la reivindicación 4 en el que la
cabecera de extensión, es una cabecera de extensión de Cabecera de
Encaminamiento Tipo 2.
6. El método de cualquiera de las
reivindicaciones 3 a 5, en el que el nodo de destino pasa desde una
primera red que incluye la primera dirección de red, a una segunda
red que incluye la segunda dirección de red, entre los períodos
primero y segundo.
7. El método de la reivindicación 2, en el que
los paquetes incluyen una dirección de origen, y el nodo de origen
transmite durante el primer período paquetes que tienen la primera
dirección de red como dirección de origen, y la dirección del nodo
de destino como dirección de destino, y transmite durante el segundo
período paquetes que tienen la segunda dirección de red como
dirección de origen, la dirección del nodo de destino en la cabecera
de extensión, y como dirección de destino la dirección de un agente
de reenvío que reenvía los paquetes al nodo de destino.
8. El método de la reivindicación 7, en el que
el nodo de origen pasa desde una primera red que incluye la primera
dirección de red, a una segunda red que incluye la segunda dirección
de red, entre los períodos primero y
segundo.
segundo.
9. El método de cualquiera de las
reivindicaciones 3 o 7, en el que uno o más nodos intermedios, a
través de los cuales los paquetes son encaminados entre el nodo de
origen y el nodo destino, leen información en la cabecera de
extensión.
10. El método de la reivindicación 9, en el que
la cabecera de extensión es una cabecera de extensión con opciones
salto-a-salto.
11. El método de la reivindicación 6, en el que
el nodo de destino pasa desde una dirección local en una red local,
a una dirección provisional en una red ajena, y envía una
realización de conexión al nodo de origen de forma que el nodo de
origen direcciona los subsiguientes paquetes en la sesión a la
dirección provisional, y pone la dirección local en una cabecera de
extensión de los subsiguientes paquetes, y donde un filtro de
paquetes basado en la dirección de destino es aplicado a la
cabecera de extensión de los subsiguientes paquetes, al objeto de
bloquear selectivamente algunos de los paquetes de datos.
12. El método de la reivindicación 8, en el que
el nodo de origen pasa desde una dirección local en una red local,
a una dirección provisional en una red ajena que contiene la
mencionada pasarela de red, y establece un túnel inverso hasta un
agente local en la red local, para reenviar paquetes al nodo de
destino, el nodo de origen pone la dirección del nodo de destino en
una cabecera de extensión de paquetes enviados desde la red ajena,
y donde la pasarela de red aplica un filtro de dirección de destino
a la cabecera de extensión de los paquetes, para bloquear
selectivamente algunos de los paquetes de datos.
13. Un método de transmisión de paquetes de
datos en una red de datos de paquetes, que comprende:
en un nodo de origen de la red de datos de
paquetes:
- \quad
- establecer una sesión de comunicación de datos de paquetes con un nodo de destino en una primera dirección de red, a través de una pasarela de red, donde los paquetes de datos tienen una cabecera que incluye una dirección de destino y una cabecera de extensión;
- \quad
- en la pasarela de red:
- aplicar un filtro a los paquetes de datos de la sesión de comunicación en función de la dirección de destino y de la cabecera de extensión de los paquetes de datos; y
- bloquear selectivamente algunos de los paquetes de datos en los que ni la dirección de destino ni la cabecera de extensión se ajusten a un criterio de dirección predeterminado; y
- \quad
- en el nodo de origen:
- recibir una indicación de una segunda dirección de red del nodo de destino durante la sesión; y
- transmitir subsiguientes paquetes dentro de la sesión, dirigidos a la segunda dirección de red y que contienen la primera dirección de red en la cabecera de extensión, para contener información a ser leída por nodos intermedios entre el nodo de origen y el nodo de destino.
14. Un programa informático que comprende medios
de codificación adaptados para llevar a cabo cada una de las etapas
del método acorde con las reivindicaciones 1 a 13.
15. Aparato que tiene medios adaptados para
llevar a cabo cada una de las etapas del método acorde con las
reivindicaciones 1 a 13.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB0226289.7A GB0226289D0 (en) | 2002-11-11 | 2002-11-11 | Telecommunications |
| GB0226289 | 2002-11-11 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2316869T3 true ES2316869T3 (es) | 2009-04-16 |
Family
ID=9947613
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03811018T Expired - Lifetime ES2316869T3 (es) | 2002-11-11 | 2003-11-07 | Filtrado de paquetes de datos en una pasarela de red que funciona como punto de aplicacion politica local basada en el servicio (sblp). |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US7554949B2 (es) |
| EP (2) | EP1561316B1 (es) |
| JP (1) | JP4690045B2 (es) |
| CN (1) | CN100454886C (es) |
| AT (1) | ATE417438T1 (es) |
| AU (1) | AU2003276482A1 (es) |
| DE (1) | DE60325264D1 (es) |
| ES (1) | ES2316869T3 (es) |
| GB (1) | GB0226289D0 (es) |
| WO (1) | WO2004045159A2 (es) |
Families Citing this family (37)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10120772A1 (de) * | 2001-04-24 | 2002-11-07 | Siemens Ag | Heterogenes Mobilfunksystem |
| GB0328756D0 (en) * | 2003-12-11 | 2004-01-14 | Nokia Corp | Controlling transportation of data packets |
| JP2005217976A (ja) * | 2004-01-30 | 2005-08-11 | Canon Inc | 電子機器及びその制御方法 |
| JP4298530B2 (ja) * | 2004-01-30 | 2009-07-22 | キヤノン株式会社 | 通信装置 |
| ES2557440T3 (es) | 2004-06-03 | 2016-01-26 | Nokia Technologies Oy | Control de portador basado en el servicio y funcionamiento del modelo de flujo de tráfico con IP móvil |
| US7512085B2 (en) * | 2004-06-24 | 2009-03-31 | International Business Machines Corporation | Method for multicast tunneling for mobile devices |
| US8265060B2 (en) | 2004-07-15 | 2012-09-11 | Qualcomm, Incorporated | Packet data filtering |
| US8042170B2 (en) | 2004-07-15 | 2011-10-18 | Qualcomm Incorporated | Bearer control of encrypted data flows in packet data communications |
| JP4405360B2 (ja) * | 2004-10-12 | 2010-01-27 | パナソニック株式会社 | ファイアウォールシステム及びファイアウォール制御方法 |
| US8166547B2 (en) * | 2005-09-06 | 2012-04-24 | Fortinet, Inc. | Method, apparatus, signals, and medium for managing a transfer of data in a data network |
| WO2007038445A2 (en) | 2005-09-26 | 2007-04-05 | Advanced Cluster Systems, Llc | Clustered computer system |
| CN1870631B (zh) * | 2005-11-11 | 2010-04-14 | 华为技术有限公司 | 媒体网关的门控方法 |
| DE602005015147D1 (de) | 2005-12-23 | 2009-08-06 | Ericsson Telefon Ab L M | Verfahren und vorrichtung zur routenoptimierung in einem telekommunikationsnetz |
| CN100442778C (zh) * | 2006-01-12 | 2008-12-10 | 华为技术有限公司 | 对数据流进行防攻击过滤的方法、系统及其重定向设备 |
| CN100512300C (zh) * | 2006-01-13 | 2009-07-08 | 华为技术有限公司 | 一种在传输实时流时业务切换的方法 |
| US8082289B2 (en) | 2006-06-13 | 2011-12-20 | Advanced Cluster Systems, Inc. | Cluster computing support for application programs |
| CN101005496B (zh) * | 2006-06-27 | 2011-09-14 | 华为技术有限公司 | 媒体网关分组过滤方法及媒体网关 |
| CN1997010B (zh) | 2006-06-28 | 2010-08-18 | 华为技术有限公司 | 一种包过滤的实现方法 |
| JP4791285B2 (ja) * | 2006-08-04 | 2011-10-12 | 富士通株式会社 | ネットワーク装置およびフィルタリングプログラム |
| KR100909552B1 (ko) * | 2006-08-21 | 2009-07-27 | 삼성전자주식회사 | 모바일 아이피를 사용하는 네트워크 시스템에서 패킷필터링 장치 및 방법 |
| US8036232B2 (en) * | 2006-08-22 | 2011-10-11 | Samsung Electronics Co., Ltd | Apparatus and method for filtering packet in a network system using mobile IP |
| CN101141386B (zh) * | 2006-09-08 | 2011-04-13 | 华为技术有限公司 | 路由优化管理方法及其装置 |
| KR100842289B1 (ko) * | 2006-12-08 | 2008-06-30 | 한국전자통신연구원 | ＩＰｖ6에서의 효율적인 대역폭 사용을 위한 통신 방법 |
| US8984620B2 (en) * | 2007-07-06 | 2015-03-17 | Cyberoam Technologies Pvt. Ltd. | Identity and policy-based network security and management system and method |
| US7844728B2 (en) * | 2007-07-31 | 2010-11-30 | Alcatel-Lucent Usa Inc. | Packet filtering/classification and/or policy control support from both visited and home networks |
| US9043862B2 (en) * | 2008-02-06 | 2015-05-26 | Qualcomm Incorporated | Policy control for encapsulated data flows |
| SE535670C2 (sv) * | 2009-04-01 | 2012-11-06 | Synapse Int Sa | Ett system och förfarande för att möjliggöra kortaste kopplingsväg för ett mobilt organ |
| SE535689C2 (sv) | 2009-04-01 | 2012-11-13 | Synapse Int Sa | Ett system och förfarande för att möjliggöra kortaste kopplingsväg för ett mobilt organ |
| US8570944B2 (en) * | 2009-05-11 | 2013-10-29 | Zte (Usa) Inc. | Internetworking techniques for wireless networks |
| US9179499B1 (en) | 2009-07-08 | 2015-11-03 | Zte (Usa) Inc. | Network selection at a wireless communication device in wireless communications based on two or more radio access technologies |
| GB2493508B (en) | 2011-07-27 | 2014-06-18 | Samsung Electronics Co Ltd | Controlling data transmission between a user equipment and a acket data network |
| US8966152B2 (en) | 2011-08-02 | 2015-02-24 | Cavium, Inc. | On-chip memory (OCM) physical bank parallelism |
| FR3004037A1 (fr) * | 2013-04-02 | 2014-10-03 | France Telecom | Procede de transport d'information de localisation au travers d'une authentification |
| CN103581189B (zh) * | 2013-11-06 | 2017-01-04 | 东软集团股份有限公司 | 应用策略的匹配方法及系统 |
| US9544402B2 (en) * | 2013-12-31 | 2017-01-10 | Cavium, Inc. | Multi-rule approach to encoding a group of rules |
| CN106257880B (zh) * | 2015-06-17 | 2019-06-28 | 北京网御星云信息技术有限公司 | 一种电磁屏蔽环境下的防火墙控制方法和系统 |
| US10382208B2 (en) * | 2016-04-29 | 2019-08-13 | Olympus Sky Technologies, S.A. | Secure communications using organically derived synchronized processes |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06112944A (ja) * | 1992-09-30 | 1994-04-22 | Sharp Corp | 情報通信装置 |
| JPH11234333A (ja) | 1998-02-13 | 1999-08-27 | Chokosoku Network Computer Gijutsu Kenkyusho:Kk | ゲートウェイ装置 |
| US6636498B1 (en) * | 1999-01-08 | 2003-10-21 | Cisco Technology, Inc. | Mobile IP mobile router |
| DE69925453T2 (de) | 1999-02-26 | 2006-05-11 | Lucent Technologies Inc. | Mobiles IP ohne Einkapselung |
| US6915325B1 (en) * | 2000-03-13 | 2005-07-05 | Nortel Networks Ltd | Method and program code for communicating with a mobile node through tunnels |
| CA2308697A1 (en) | 2000-05-15 | 2001-11-15 | Nortel Networks Limited | Exclusion routes in border gateway protocol (bgp) routers |
| US6621793B2 (en) * | 2000-05-22 | 2003-09-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Application influenced policy |
| FR2812783A1 (fr) | 2000-08-03 | 2002-02-08 | Cit Alcatel | Procede de transmission d'informations par paquets avec allocation de ressources et reseau mettant en oeuvre ce procede |
| GB2366480A (en) | 2000-08-21 | 2002-03-06 | Lucent Technologies Inc | Method of operating a third generation mobile communication system |
| GB2366482A (en) | 2000-08-21 | 2002-03-06 | Lucent Technologies Inc | Method of operating third generation communication systems |
| JP4491980B2 (ja) * | 2001-03-05 | 2010-06-30 | ソニー株式会社 | 通信処理システム、通信処理方法、および通信端末装置、並びにプログラム |
| CN2485724Y (zh) * | 2001-03-16 | 2002-04-10 | 联想(北京)有限公司 | 网关级计算机网络病毒防范的装置 |
| JP2002290444A (ja) * | 2001-03-23 | 2002-10-04 | Mitsubishi Electric Corp | 移動体通信システム、通信方法およびパケットフィルタリング制御方法 |
| GB0113901D0 (en) | 2001-06-07 | 2001-08-01 | Nokia Corp | Security in area networks |
| US7123599B2 (en) * | 2001-07-13 | 2006-10-17 | Hitachi, Ltd. | Mobile communication system |
| WO2003015356A1 (en) * | 2001-08-08 | 2003-02-20 | Fujitsu Limited | Server, mobile communication terminal, radio device, communication method for communication system, and communication system |
| JP2003209890A (ja) * | 2001-11-07 | 2003-07-25 | Matsushita Electric Ind Co Ltd | 移動通信方法および移動通信システム |
| US6973086B2 (en) * | 2002-01-28 | 2005-12-06 | Nokia Corporation | Method and system for securing mobile IPv6 home address option using ingress filtering |
| US7272148B2 (en) * | 2002-06-27 | 2007-09-18 | Hewlett-Packard Development Company, L.P. | Non-ALG approach for application layer session traversal of IPv6/IPv4 NAT-PT gateway |
| WO2004028053A1 (en) * | 2002-09-18 | 2004-04-01 | Flarion Technologies, Inc. | Methods and apparatus for using a care of address option |
| US7466680B2 (en) * | 2002-10-11 | 2008-12-16 | Spyder Navigations L.L.C. | Transport efficiency optimization for Mobile IPv6 |
-
2002
- 2002-11-11 GB GBGB0226289.7A patent/GB0226289D0/en not_active Ceased
-
2003
- 2003-11-07 US US10/534,662 patent/US7554949B2/en active Active
- 2003-11-07 JP JP2004550789A patent/JP4690045B2/ja not_active Expired - Fee Related
- 2003-11-07 DE DE60325264T patent/DE60325264D1/de not_active Expired - Lifetime
- 2003-11-07 EP EP03811018A patent/EP1561316B1/en not_active Expired - Lifetime
- 2003-11-07 WO PCT/GB2003/004812 patent/WO2004045159A2/en active Application Filing
- 2003-11-07 ES ES03811018T patent/ES2316869T3/es not_active Expired - Lifetime
- 2003-11-07 EP EP07015464A patent/EP1860834A1/en not_active Withdrawn
- 2003-11-07 AT AT03811018T patent/ATE417438T1/de not_active IP Right Cessation
- 2003-11-07 AU AU2003276482A patent/AU2003276482A1/en not_active Abandoned
- 2003-11-07 CN CNB2003801030432A patent/CN100454886C/zh not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP1561316A2 (en) | 2005-08-10 |
| GB0226289D0 (en) | 2002-12-18 |
| WO2004045159A3 (en) | 2004-09-16 |
| EP1561316B1 (en) | 2008-12-10 |
| AU2003276482A1 (en) | 2004-06-03 |
| WO2004045159A2 (en) | 2004-05-27 |
| EP1860834A1 (en) | 2007-11-28 |
| US20060104284A1 (en) | 2006-05-18 |
| ATE417438T1 (de) | 2008-12-15 |
| DE60325264D1 (de) | 2009-01-22 |
| US7554949B2 (en) | 2009-06-30 |
| CN100454886C (zh) | 2009-01-21 |
| CN1711728A (zh) | 2005-12-21 |
| AU2003276482A8 (en) | 2004-06-03 |
| JP4690045B2 (ja) | 2011-06-01 |
| JP2006506007A (ja) | 2006-02-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2316869T3 (es) | Filtrado de paquetes de datos en una pasarela de red que funciona como punto de aplicacion politica local basada en el servicio (sblp). | |
| CN110268734B (zh) | 使用不可信网络的互通功能 | |
| ES2284482T3 (es) | Optimizacion de encaminamiento de ip en una red de acceso. | |
| ES2237079T3 (es) | Metodo de control de acceso para un sistema de comunicaciones moviles. | |
| JP4270888B2 (ja) | Ｗｌａｎ相互接続におけるサービス及びアドレス管理方法 | |
| US7437154B2 (en) | Heterogeneous mobile radio system | |
| ES2449574T3 (es) | Método y aparato para itinerancia entre redes de comunicaciones | |
| ES2384498T3 (es) | Habilitación del uso simultáneo de una red local y una red externa mediante un nodo móvil muti-proveedor | |
| ES2331141T3 (es) | Una arquitectura de red y un metodo relacionado con el acceso de estaciones de usuario. | |
| JP4444833B2 (ja) | 電気通信 | |
| ES2347652T3 (es) | Agente movil distribuido. | |
| ES2548005T3 (es) | Técnica para proporcionar soporte a una diversidad de protocolos de gestión de la movilidad | |
| KR100988186B1 (ko) | 다중 네트워크 상호연동에서의 홈 에이전트에 의한 동적 홈어드레스 할당 방법 및 장치 | |
| US20140177553A1 (en) | Method and apparatus for data transfer in a packet-switched network | |
| CN102656861A (zh) | 因特网协议移动性安全控制 | |
| US9641999B2 (en) | Telecommunications | |
| ES2345715T3 (es) | Restriccion de servicios en redes de comunicaciones moviles. | |
| JP2010517344A (ja) | ルート最適化手順によるデータパケットのヘッダ縮小の方法 | |
| JP4834133B2 (ja) | 電気通信 | |
| JP2007520963A6 (ja) | 通信 | |
| JP4802238B2 (ja) | ローカルネットワーク相互接続における移動端末に対してネットワークに基づくトンネルを設定する方法 |