Network 전사적 QoS 보장 기술 (cont.)

Download Report

Transcript Network 전사적 QoS 보장 기술 (cont.)

Internet QoS Technique
Jun-Hyun, Moon
Computer Communications LAB.,
Kwangwoon University
[email protected]
개요

인터넷의 확산
 IP 기술의 단순성에 근거
 대부분의 지능을 Network 종단이 가짐
 Network 내부에서는 Destination Address를 바탕으로 단순하게
정보를 전달함
 Router Resource 여부에 따라 Data의 Delay 혹은 Loss 발생
 Simple Best-effort Service
 사용자의 수의 폭발적인 증가와 다변화된 응용 및 Service 요구
 대용량의 Bandwidth
 엄격한 시간적인 전달 요구 사항
 일대다/다대다의 전달 요구 사항

QoS 관리 기술 필요
Network 응용 분류표
최선형
다방향
(many-tomany
bidirectional)
Asynchronous Burst
- News
- Session
announcement
양방향
(one-to-one
bidirectional)
단방향
(one-to-one or
one-to-many
unidirectional)
Asynchronous Burst
- E-mail
- File Transfer
- Push Media
(출처: iBand2 백서)
통제형
보장형
Interactive Stream
- Distance learning
- Multi-Player games
Interactive Burst
- Chat (IRC)
- Resource discovery
- Shared editing
Isochronous Stream
- A/V Conferencing
- Distributed simulation
- Real-time modeling
Mission-Critical Stream
- Distributed process
Mission-Critical Burst
- Auction
Interactive Stream
- Thin client
- X-windows
Interactive Burst
- Web browsing
- Resource sharing
- Database access
- POS transactions
- Remote login
- Chat (text-based)
Isochronous Stream
- Telephone
Isochronous Burst
- Database updates
Mission-Critical Stream
- Telemedicine
- Remote control
Mission-Critical Burst
- Financial X-actions
Synchronous Stream
- Streaming media
- Data collection
- Push media
Isochronous Stream
- Data collection
- Process monitoring
- Push media
Mission-Critical Stream
- Data collection
- Process monitoring
- Push media
QoS 정의
주소/이름 인식성
이용/제어 품질
Service 제어성
자원 이용 효율성
QoS
홉 레벨 품질
• Latency Time
• Interactivity
• Traffic Engineering & Policy
• Resource Management
• Hop-level QoS
표현/체감 품질
종단 레벨 품질
• End-to-End-level QoS
QoS 기술

Network 전 계층(응용~물리)에서의 보장 기술
 응용
 성능에 맞는 설계 및 Network Service 품질의 차이를 활용할 수 있
는 Interface 및 Link 기능 지원
 라우터나 스위치
 Traffic의 특성에 맞는 Resource Management and Scheduling

Network 종단간 QoS 보장 기술
 QoS 요소 변수들을 제어할 수 있는 Network Service 측면의 제
어 Mechanism이 필요
 망 장치에서의 Delay
 Throughput
 Loss 특성
 Reservation, Queuing, Monitoring
 QoS Management, Security, Traffic 측정, 분석 및 과금 기능
QoS 관리 기술 분류

QoS 보장 기술
 Network 장비에서 제공되어야 할 Traffic 관리 기술
 Network 전사적인 QoS 보장 기술
 Policy기반의 QoS 관리 기술

QoS monitoring 기술
 Protocol monitoring
 Network monitoring
 End-to-End QoS monitoring
특정 장비별 QoS 보장 기술 : Traffic Management

Queue management
 FIFO, Priority Queuing, CBQ, WFQ

Traffic shaping
 Leaky-Bucket, Token-Bucket, 복합방식



Admission control
Policing
Congestion control
 RED, WRED, ERED, GRED
Queue management

FIFO Queuing
 Store-and-forward 방식
 High bandwidth, Switching/Forwarding 성능이 뛰어난 Bust
Traffic 처리에 적합
 Overflow가 발생할 경우 Service의 종류와 무관하게 Drop이 발생
 차별적인 Service 제공이 어려움

Priority Queuing
 특정유형의 Traffic을 구분하여 출력 Queue의 앞부분으로 보내 먼
저 처리되도록 하는 방식
 가장 초보적인 Service 차별화가 가능
 Service 차별화 단계가 많을수록 처리 부담 가중, Packet
Forwarding 성능 저하
 낮은 우선 순위의 Loss율이 높고, Delay에 민감한 응용에는 비적
합, 확장성이 좋지 못함
Queue management (cont.)

Class-based Queuing (CBQ)
 Priority Queuing 방식의 단점인 Starvation 현상을 방지
 하나의 출력 Queue 대신 여러 개의 출력 Queue를 Class 별로
두어서 Priority를 정하고 각 Queue별로 Service되는 Traffic의 양
을 조절
 특정 Class의 Traffic이 전체 System Resource를 독점하는 것을
방지
 각 Class별로 정해진 양의 Bandwidth을 완전 보장하지는 못함
 Class별로 자원이 완전 고갈되는 것을 막으면서도 각 Class별로
적절한 Service를 제공 할 수 있는 방식
 복잡한 Queue 관리에 소요되는 계산 부담 때문에 고속의
Network의 경우에는 Scalability 문제가 있음
Queue management (cont.)

Weighted Fair Queuing (WFQ)
 소량의 Traffic이 대량이 Traffic에 의해 피해를 보지 않게 함
 Flow별로 Traffic을 조절하는 공정성 측면
 특정 기준에 따라 가중치(Weight)를 둠
 같은 양의 Traffic을 가진 Flow 간에도 차별을 두는 Weight 측면을
복합적으로 적용한 Queuing 방식
 Weight를 결정하는 방식
 구현 방식 의존적
 예) IP Header의 TOS 필드 중 IP precedence bit를 사용하는 경우
 고속의 Network 환경에서 Scalability 문제
 Traffic Flow 간을 차별화 할 수 있는 Mechanism 부재로 인한
granularity 부족이 이 방식의 최대 단점
Traffic Shaping

Network 내부로 유입되고 유출되는 Traffic의 양과 유출
되는 Traffic의 속도를 조절하는 Mechanism

Leaky-Bucket 방식
일정하지 않은 Traffic을 일정하게 유지시켜 전송시키는 방식
ATM Network에서 Cell Traffic의 속도를 조절하기 위해 제안
Packet Network의 제 3계층에서도 사용됨
Network로 전송되는 Traffic을 아주 단순히 제어하고 조절 가능
구현이 쉽고 Network 내의 한 종류의 Traffic 양을 조절하는 임
의의 임계치(threshold)로 사용가능
 여러 종류의 Traffic 속도를 지원해야 하는 경우에는 비효율적
 Leak late이 고정된 값을 가지므로 Network 자원의 여유가 많
은 때에도 충분히 활용할 수 있는 적응성이 부족함





Traffic Shaping (cont.)

Token-Bucket 방식
 Bucket 자체를 FIFO Queue로 사용하지 않고 Traffic을 제어하기
위한 Control Token을 관리하는 용도로 사용
 Traffic은 Token의 유무에 따라 Flow Control을 받게 됨
 항상 정해진 일정양만 통과하도록 되어있는 Leaky-Bucket과 달
리 Traffic이 Bust한 경우에도 일정한 한계치 범위 내에서 통과 가
능
 Network의 Resource 활용을 보다 효율적으로 할 수 있음
 다수 개의 Token을 허용하는 변형된 방식으로 발전
 서로 다른 Class Traffic의 개별적인 조절이 가능함

복합 방식
 Token-Bucket으로 Traffic 양의 Bust를 허용하면서 조절한 후,
Leaky-Bucket을 이용 특정 한계치 값만큼 일정하게 Traffic 전송
 다수의 Token-Bucket이 가질 수 있는 특정 Class의 자원 독점 혹
은 경쟁 방지, Traffic Class의 차별화 구현 용이
Admission Control


특정한 Traffic을 Network로 받아 들일 것인가의 여부를
결정하는 정책
Admission Control을 하지 않을 경우
 Network 내부에서 발생할 수 있는 다양한 문제점들에 대해 해
결책을 제시할 수 없음
 근본적인 QoS 보장이 불가능해짐


QoS 제공을 위한 필수적인 요소
Admission Control의 종류
 Leaky-Bucket 혹은 Token-Bucket을 이용하는 단순한 방법
 복잡한 QoS 변수를 적용하여 Admission Control을 하는 통합
Service Model
 Resource의 유무와 별도로 Network 자체의 Policy에 따른
Admission Control 방법
Congestion Control

Random Early Detection (RED)
 Queue 길이를 측정하여 관리자가 설정한 한계치 값에 접근하면
임의로 특정 Flow를 선택하여 Packet을 Drop시킴으로써 Sender
측에서 송신 속도를 늦출 수 있도록 함
 글로벌 동기화 현상을 방지할 수 있음
 FIFO Queuing 방식의 단점인 Packet 순서 조정 및 Queue 관리에
소요되는 계산 부담없이 Congestion Control를 할 수 있음
 혼잡 발생 시 임의의 Flow를 선택하여 Drop 시키기 때문에
Service의 차별화를 두어야 하는 환경에서는 공정성을 유지하기
어려움

Weighted Random Early Detection (WRED)
 RED의 단점을 보완, Service의 차별성을 유지하면서도
Congestion Control을 할 수 있는 방법
 혼잡발생 시 탈락시킬 Flow를 특정 기준(Policy)에 준하는 값에 따
라 Priority를 두고 선택하도록 하는 방법
Network 전사적 QoS 보장 기술

End-to-End per-flow Resource Reservation-Integrated Service
 각 Flow 별로 응용 종단간에 필요한 Resource을 예약하고 사용
 구성 요소
 Admission Control
 QoS 요구사항을 Node가 만족할 수 있는지를 판단하여 연결 여부 결정
 Classifier
 수신된 Packet의 Header 정보(수신자 정보, Protocol Type, Port번호) 식별
 Scheduler
 Service될 Class 결정
 Resource Reservation Signaling Protocol
 ReSource reserVation Protocol (RSVP)
 가장 정확하게 개별 Flow별로 원하는 QoS 보장 가능 기술
 문제점
 RSVP가 Soft-state Protocol임으로 인해 발생되는 Scalability 문제
Network 전사적 QoS 보장 기술 (cont.)

Integrated Service over Differentiated Service
 Service Code Point (DSCP) 필드에 의해 Service 수를 제한
 Packet Classifier, Marking, Policing, Shaping 등을 망의 Edge
Node에서 수행
 Core Node에서는 Behavior Aggregate (BA) Classifier만 수행
하여 Scalability 문제 해결
 세가지 Service 유형
 Best-effort Service
 일반적인 최선형 Service
 Assured Forwarding (AF) Service
 망이 혼잡할 때 일정수준의 Service 품질을 보장하는 Service
 SLA 준수 여부에 따라 Traffic을 in 또는 out Profile로 분류 Assured
Queue에 넣고 RED 또는 RED with In and Out (RIO)로 스케쥴링
 Expedited Forwarding (EF) Service
 Low Jitter와 Delay 보장, Premium Service
Network 전사적 QoS 보장 기술 (cont.)

Integrated Service over Differentiated Service (cont.)
 SLA를 초과하는 Traffic은 Drop
 Egress Router는 SLA에 따라 Shaping 기능 수행
 Integrated Service (IS)의 단점을 보완하기 위해서 제안됨
 Back-bone : DiffServ를 사용함으로 확장성 보장
 User Network : IntServ를 사용함으로써 확실한 QoS 보장 가능
 단점
 DiffServ Network을 Black-Box로 취급하고 내부의 Resource
Status를 알 수 없기 때문에 User Network의 Edge Node에서 정확
한 Admission Control이 어려움
 DS Network내에서 Congestion을 Edge Node가 알 수 없음
 해결책
 Bandwidth Broker (BB)를 이용 해결 가능
Network 전사적 QoS 보장 기술 (cont.)

Integrated Service over Differentiated Service (cont.)
 Bandwidth Broker (BB)
 Internet에서 QoS를 제공함에 있어서 Policy 기반 QoS 관리 기능
중에서 자원사용량에 기반한 QoS 관리를 수행하는 System
 Domain에 하나씩 존재
 Inter-domain
 이웃 Domain의 BB와 SLA 체결 유지하는 기능
 Intra-domain
 User나 응용으로부터의 QoS Requirement를 받아서 Domain 내의
Resource 사용 Policy에 따라 Resource를 할당하는 기능 수행
 이웃 Domain과 협상된 SLA에 기반하여 Border Router의 Resource
구성 정보를 제공
Network 전사적 QoS 보장 기술 (cont.)

Statically Assigned Trunk Reservation based on
DiffServ
 여러 개의 Per-Flow를 하나의 Aggregate-Flow로 묶어서 처리
하는 방식
 Static한 Aggregate Flow 설정
 Network 구조는 IntServ over DiffServ와 동일하지만 resource
reservation을 각 Per-Flow가 아니라 Aggregate-Flow로 처리하
는 차이가 있음
 Scalability 문제 해결 가능
 하지만 여전히 IntServ over DiffServ 방식의 문제점 계승
 표준화된 Admission Control 방식의 부재
 Admission Control을 어디서 할건지?
 DS Network의 Ingress or Egress……
 Resource 설정 범위
 Global Network or 각각의 Aggregate Path…...
Network 전사적 QoS 보장 기술 (cont.)

Dynamic Trunk Reservation with Aggregated RSVP
 통합 Flow인 Trunk를 Dynamic하게 Setup하는 방식
 Truck의 Dynamic Setup을 위한 Dynamic Signal Protocol
 Aggregated RSVP
 이동성이 강한 Network나 Over-Provisioning이 허용될 수 없는
Network에서는 이 Protocol 만으로는 해결될 수 없는 문제점이 있음
 Aggregated RSVP는 RSVP의 확장 버전이기 때문에 RSVP의 문
제점인 수신자 기반, 단방향성 및 관련 Node수에 비례한
Resource Status Management 등을 가짐
 따라서 보다 강력한 Dynamic Signal Protocol이 필요함
Policy-based QoS Management

Policy-based QoS Management의 정의
 End-to-End QoS 보장을 위해 Network 내부 또는 외부 전체의
Network 요소 내부의 Traffic 관리 기능 제어 및 Resource를 종합하여
관리 하는 System

Policy-based QoS Management의 구성
 Policy 편집
 Network와 User의 Policy을 생성
 Policy 충돌 방지
 기존의 Policy과 새롭게 생성된 Policy과의 충돌을 감지하고 관리
 Policy 생성
 Network 장비가 이해할 수 있는 형태로 Policy을 변경 생성
 변경 생성된 Policy 정보는 Network 장비에 분배되고 각 장비는 분배된
Policy를 적용하여 Traffic을 제어함
 Policy 진화 가능
 이미 분배된 Policy은 Network의 Status나 특정 일시 등과 같은 영향으로
변경을 요하는데 이것을 감지하고 관리하는 기능
Policy-based QoS Management Architecture
Policy Tools
Policy
Definition
(including Validation &
Conflict Detection Logic)
LDAP
Directory
Policy Decision Points
Network QoS
PDP #1
Proxy 1
…
Security
PDP #1
Proxy 2
Policy Enforcement Points
…
Combined
PDP and
PEP
Policy-based QoS Management Architecture (cont.)

Policy Tools
 including Validation & Conflict Detection Logic

LDAP Directory System
 Policy Store and Search

Policy Decision Points (PDP)
 생성된 Policy를 Network 장비가 이해할 수 있는 형태로 변환하
여 전달하고 이에 대한 응답을 받아 처리하는 기능을 수행

Policy Enforcement Points (PEP)
 Policy를 받아서 각 장비가 이해하는 명령어로 변환하여 수행하
는 역할

Policy Proxy
 장비에 PEP 기능이 없을 경우 이 기능을 대신해 주는 요소
Policy-based QoS Management Architecture (cont.)

Common Open Policy Service (COPS)
 PDP와 PEP 사이의 Policy 정보 전달 Protocol

Light Weight Directory Access Protocol (LDAP)
 PDP와 PEP가 Policy 정보를 저장, 검색, 획득하는데 사용되는
Protocol
Policy-based QoS Management Protocol

Policy Protocol의 정의
 각 Routing System에서 User Data 전달 요구를 수신하였을 때
User가 적용할 수 있는 Policy에 따라 User를 받아들이거나 거
절하는 기능을 수행하기 위하여 Router와 Server간에 동작하
는 Protocol

Policy Protocol에 대한 요구사항







신뢰성
적은 지연
Opaque objects 전송 기능
PEP-initiated, Two-way Transactions 기능
Asynchronous notification 기능
Multicast group 처리 기능
QoS Specification 기능
Policy-based QoS Management Protocol (cont.)

기존의 Policy Protocol
 RADIUS
 LDAP
 Simple Network Management Protocol (SNMP)

COPS
 Resource Allocation Protocol 그룹에서 제안
 용도
 Outsouring : COPS-RSVP
 IntServ Domain에서 DiffServ Domain으로 Resource Reservation을
할 때 DiffServ Border Router에서 요청된 RSVP 예약 신청을 승낙할
것인지의 여부를 Policy Server의 결정에 따르는 경우
 Provisioning : COPS-PR
 Server에서 직접 Policy를 Network 장비에 설치를 요청할 경우에 사
용
 BB의 기능 중 Domain 내부 Resource Reservation 기능
QoS Monitoring 기술

QoS Monitoring 기술의 분류
 Traffic Measurement
 Traffic Analysis
 Traffic Presentation

Monitoring 범위에 따른 분류
 Protocol Monitoring
 Network Monitoring
 End-to-End QoS Monitoring

Monitoring 방식에 따른 분류
 Passive 방식
 Protocol Monitoring or Network Monitoring
 Active 방식
 End-to-End QoS Monitoring
QoS Monitoring 기술 (cont.)

Protocol Monitoring
 특정 QoS 구조를 가지는 Network Domain에서 사용되고 있는
Protocol이 제대로 작동되고 있는 지를 점검하는 기술
 특정 QoS 관리 구조의 완결성을 확인할 수 있는 좋은 기준임
 예) RSVP Protocol Monitoring Tool – RSVP Diagnostics Tool

Network Monitoring
 Network Resource의 가용정도 및 소비정도를 측정하여 전반
적인 Status를 Monitoring함으로써 Network Engineering과 관
리에 도움을 줌
 기존의 SNMP 기반의 Network 관리 Tool을 활용하여 QoS 보
장 관련 기술용 MIB을 구현함으로써 Monitoring 가능
 예) Real-time Traffic Flow Measurement (RTFM) 구조 Tool
QoS Monitoring 기술 (cont.)

End-to-End QoS Monitoring
 이질적인 QoS 관리 구조를 가지는 Network Domain간의 QoS
보장의 제공 여부를 점검하는 데 중요한 기능을 함
 원하는 Traffic 생성을 원하는 시점에 원하는 양 만큼을 할 수 있
는 Tool 과 그 결과를 Monitoring할 수 있는 Tool이 필요
 정확한 Timing, 다양한 종류의 Test Traffic으로 정확한
Monitoring이 상당한 어려움으로 신중한 사전 설계와 구조의
정의가 요구됨
기타 기술

Traffic Engineering
 Network Resource의 효율성 극대화 및 신뢰성 향상 기술
 QoS를 보장하면서 동시에 Network Resource를 효율적으로
사용하기 위한 기술
 주요 Traffic Engineering 기술
 Destination Path Calculation and Signaling
 Traffic Distribution
 Alternative Path Routing and Problem Path Recovery
 대표적인 예
 MPLS (Multi Protocol Label Switching)